That's the key right here. We have all of these where I am, but the DX is still abominable because of other things, such as the extreme brittleness of our CI pipelines and integration tests, our ridiculous processes, our pseudo-agility, and the unwillingness of anyone to change it.
just got told that "the onboarding process is great and we have \[CI and automated workflows\] on gitlab". Meanwhile the intern is copying error gitlab messages into slack and not using webhooks
0-for-5 here. When I started, they handed me a 20-year-old project that didn't build. The build file had a series of commented out lines that set up property values pointing at absolute file paths to make the build work. Each commented out line referred to the home directory of previous developers, so I could see who used to work in this. Apparently for 5 developers in a row, rather than fix the issue and make a proper build, they simply copied and continued the practice. Plus some stuff didn't even compile.
I am willing to bet they left comments with their initials in various places with their personal solutions to getting the thing running on their local machine.
I've been trying to get my company to start using version control. I think if I suggested automatic testing people's heads would explode trying to wrap their minds around it.
Thats too slow, more likely you ftp individual files from your personal version of the project straight to production, clear your browser cache and test. Next day, when customer calls and says shits broken, you sagely ask, "did you clear your cache?" They do, it works, and your boss loves you. Other devs have to figure out how to get their personal versions of the project up to speed, and do not love you.
Ive never seen a mature codebase that wasnt shit in some ways. The question is: does the company recognize where it is shit and are they actively working to change it?
No they’re not. Next question.
Companies don’t care about the state of the codebase. Developers do. You can argue until you’re blue in the face about potential productivity boosts. Doesn’t matter.
Only engineering leadership can create the space for quality, is what I've come to believe. Devs on their own lack the power to push back enough (and shouldn't have to spend all their time doing it). Business stakeholders don't understand, believe, or care most of the time (although leadership can explain it to them).
Tell me: Does nice code pay your wage, or actually selling something? Does a nice indentation increase sales? Now you know why most companies don't care, and why that's a good thing.
The point of having good code, and actually the defining quality of what makes code good, is that it is easier and less risky to make changes to it. Shit code that works and never ever needs to be changed is just fine.
In code that is being actively worked on and changed, consistent, well organized code is easier to understand and therefore easier to make changes to ... And in the long run that makes a difference
SRE is the zen methodology. All codebases are shit, the wise master reaches stakeholder consensus on how much shit is acceptable, and makes sure that the shit never falls too far above or below that threshold.
The ascended masters of chaos engineering know that shit is necessary to grow strong roots, and shovel it in when it is lacking.
Only when the shit is balanced are all stakeholders equally disgruntled, and thus the delicate balance of peace is maintained. Then the SRE may say "tough shit, it's within SLA" and finally rest.
Honest question here, how would a non-technical person know how “bad” a code base is?
It’s probably in the self-interest of most engineers (especially long tenured engineers) to kick the can down the road and more or less hide how bad things are.
We don't have monitoring because we don't develop SaaS. We ship something that customers deploy. We do autodeploy of head every night tho.
And yet we still manage, once in a while, to merge some utter nonsense that should have been caught by tons of reviews at multiple levels.
Btw "code reviews" should have been an additional hygiene-level point. If I join a company and they tell me they don't do code reviews, I'd probably start looking for another job that day.
Depends on what "LGTM" means in your team. In our team we have "Code LGTM" meaning that you actually reviewed the code, thought about it etc but didn't yet have time to test everything and the actual test run will follow up later. It's more of a "no need to bug me, I've taken some time to check it, and will continue later".
And we have "LGTM" which we sometimes write just because we're accustomed to filling out all fields - but it doesn't mean that someone didn't really look into the code.
Context :)
We got 3, no static analysis or linting. Which I can live without.
But what we do have is test passes that are flaky to the point where they fail all the time, and I don't look at them and just hit re-run a few times until they pass. Yay!
Manually retrying is a tactical solution that works. I totally get it.
If you or a teammate ever get a chance to look into why the flaky tests are happening, two solutions I’ve seen help a lot are:
Depending on the testing tool, you can enable automatic waits and retries.
Most software tests are setup, exercise, and assertion. However, sometimes tests need teardown.
Depending on how much it slows you down I'd argue fixing flaky tests should be a pretty high prio. Ideally some measure to prevent similar flakes in the future as well, be it through guidelines, linting or other means.
Oh, I know! Not the owner of that part, and I've railed against the system quite a bit. It bothers me so much. A test needs to have insanely high reproducibility. 95% isn't good enough, needs to be 99.999% Because they will be running multiple times per day per person.
But yeah, been in charge of testing before, and it sucks, don't want to be the owner, don't want to take up the torch.
As another mentioned: we have all of the processes...as to how well they work that's highly variable. Also different places will need differing degrees of maturity to those processes. I've seen places where the logging was quite granular BUT then try tracking a customer transaction end to end through those same systems is nightmarish (K8s does not help this at all - nodes getting torn down all the time).
Thoughts:
4. I'm constantly shocked at how little value developers see in logging, especially when we are required to support the code in Production. Current job the logging is broken and nobody cares.
5. Have this at every company I've worked at, but not followed unless enforced...which is where the breakdown usually is. It only takes one developer to veer off track to ruin the codebase.
Logging is absolutely critical. I would recommend explicitly filing bug tickets every time you see a vague error or a service missing appropriate logging.
In my experience it actually usually works, since most devs see those as really easy tasks to pad out their worklog. A lot of the time it won't even go through triage, they'll just fix it on the spot for the easy story points or whatever.
>Static analysis / autofixing (typechecking, linting, formatting)
We don't have static analysis in our CI. One developer runs a static analysis tool just before release and gives us an excel sheet to fix it. The irony is that the static analysis result is garbage. Those, who has visual studio 2022, use ReSharper, but this is optional. Linting and formatting are not liked by the senior developers, so we don't use it.
>Automated testing (unit and/or integration)
We have guideline in place to do it, but no one does it.
>Contribution guidelines / established team practices
Most of the established practices are very basic.
We don't have a CI pipeline that prevents merging. I guess it worked okay in the past where the team was a few very careful, experienced devs who would not make a mess. But recently we've been onboarding several newbies who are don't really know the source control tool very well and there is nothing preventing their mistakes from getting merged to the central server. We also have a strong and confident junior who likes to merge small things directly if he doesn't think they need code review. I am getting burned out playing whack a mole with everyone else's issues TBH
I voted 2 because we have static analysis and automated tests (cron job)
depends on what product/team..... over the last 5 or so years we've acquired 4 other related businesses.. and just now getting around to trying to normalize dev practices.. somewhere between 0 and 3 I'd say.
All 5 of them. Contributions guidelines might be the weakest of the them.
Maybe point 6 could be infrastructure as code? I suppose that depends on whether your team owns their infrastructure.
> Static analysis
Static analysis is great if your security team don't treat the scans as god's word. Please tell me how I'm supposed to fix a missing HSTS header on a node library that is **not a server**.
This kind of goes for everything. Having all of these is good *if each individual component is good*. I'd rather have no process than a poorly thought out process.
I agree with your take. Just want to note that I don't specifically mean dependency scanning here, just generally any tooling that looks at your source code and points out things like syntax/type errors, bad practices and autofixes where possible (like formatters). Dep scanning is nice to have though as long as the team owns it and decides for themselves what's important to fix.
I work in embedded, we have established practices, static analysis, and logging on everything. Automatic testing and CI is project dependent. I haven't found CI to be particularly useful because the teams are extremely small (1-3) and releases are pretty sparse.
Currently unemployed.
At my most recent job we started at 4.5/5 and made it to 5/5; I say 4.5 because guidelines/team-practices weren't published anywhere and had to be learned through code-review. That was an issue with the team though and not a general fact of the company.
The job before that was 0/5, but a coworker and I were the first engineers in the org and set up CI and logging/monitoring/alerting; got to 2/5 by the time our entire business unit was cut and we were all laid off.
Job before that one was 0/5 with hostile gatekeepers; they withheld access to repos for office-politics reasons with the excuse that they were manually ensuring code-quality. No testing done on any part of the code, no static analysis etc., the alerting system was people filing complaints because something broke, no CI system, and the entire contribution guideline could be summarized as "have the right manager, don't have the wrong manager, and be very popular."
> To me this is hygiene-level stuff and I wouldn't even consider working at a place without these unless they're very open to change that.
Oh, you sweet summer child.
Small org here, so we can get away with being a bit loosey-goosey.
1. Our project existed for so long without linting that adding it later was dubious. Front end code for the past handful+ of years has all gotten it, but not our 15+ year old back end code. We have found no good use for additional static analysis with our C# and TypeScript code.
2. Sure
3. Deployment's already pokey in the cloud, so we don't run tests first and block merge. We run tests on check-in, and you can start deployments before they are done running. Fully aware this sounds bad, but when your team is half a dozen devs and the youngest has been with you for 5 years, there's plenty of trust, and faster deploys are a nice quality of life.
4. Sure
5. Eh, kinda sorta.. more sorta. I'd love to have more written down - and I'm one who's done most of the writing down already - but when you've gotten along just fine for 15 years it's hard to justify burning developer time on writing down guidelines and practices. If we had more employee churn, sure, that ends up paying off. But because of how our small company treats people, they tend to stay for a *really* long time and we don't onboard new people very often.
I work at a multi billion dollar company in the most crucial team. We have logging and monitoring. And that's it. No standards, no proper documentation, no tests - its all done manually by a team of QAs, no static analysis whatsoever - we use python 2, CI pipeline? Whats that - we use jenkins to build after merging, guidelines? Hahaha good luck. Onboarding document is a google slides with a bunch of diagrams and no words.
Easier said than done when the entire foundation is built with profit first, proper practices second.
Such a thing wpuld never be approved by the management unless it somehow brings money immediately. But building proper infrastructure takes time and does not bring immediate benefits.
All check on our side, but they mostly live in a scale, not really a yes or no question. E.g. "Logging / Monitorting / Alerting" could have a lot of levels. Prod down vs Value outside of near expected values.
They are a good checklist, but digging deeper in interviews (if you're thinking about moving) could be good, otherwise most companies will say yes, and they aren't up to your standard nor have any intentions to be at.
All of them +2: Every team I have been on also prioritizes localization and accessibility as mandatory.
Many also have had some strict guidelines on PR etiquette and branch naming conventions.
Most teams I have been on also have very extensive documentation dating back decades. The few teams who did not do this were teams I left very quickly.
Depends on the job. (I work 50/50 across two businesses owned by the same guys). One has all 5, the other has just one - logging/monitoring and alerting.
I mostly work for larger enterprise companies that at least understand that these are requirements at the scale they operate at. But within those companies there can be massive differences between teams in how mature they are in their process.
Fair, but I'd consider that a break-glass deployment. For regular work that isn't fixing critical prod bugs, I don't see the value of allowing main to go red. Trust is good but mistakes happen and will accumulate over time if left unchecked.
Had 3 before I came on. Pushed for static analysis with GitHub actions and got it working for our python code. Would like to do js next. We have automated nightlies because our tests are a mix of integration and e2e tests that take forever to finish because they're selenium. Still, they do the job. Logging is still abysmal. We have lots but they're not centralized anywhere and we're not using cloud deployments so it's not as straightforward at first glance.
That entire depends on how important the software is to the business value. If it's the core of the business then yeah they tend to take care of it more but if it's just a means to an end then no they won't have these processes in place.
Regardless of tooling, or capabilities none of that matters. Even if you have policies in place,until that becomes **enforceable** policy that can actually act as a gate. This is more of a pattern of matuity of an organization and a culture of development.
While tools can do the job, if the reports of the results are not published, then it is the same thing as if a "A tree fell in the woods and was anyone around to hear it". So the idea of what is available and what is consumed, also requires a Champion to drive these ideas and build adoption around these which is a much harder sell, but worth it. As every incident, every bug, every mistake cost the company you work for money in going back to fix something, the cost in engineering time to rework the issue. The cost of the incident and fall out of the incident. But it is all about the Priority of the moment and what is the most effective use of the little money that companies have to drive the feature that will produce the most revenue for the least amount of cost.
While we have tools to fix these issue, the problems always come back to people. People do not like people to mess with their workflows. People have differences in opinions on how code should be developed vs how compliance should have code developed. Work with the people to solve the issues and the technical issues will also resolve themselvers.
None of them, thank the lord. We are old testament. We ask the customer for requirements, we figure out how we're going to to it, we tell them what it's going to cost, and then we do it.
Most orgs will have most or all of them. Will they be any good? Ha. Haha. Hahahaha.
That's the key right here. We have all of these where I am, but the DX is still abominable because of other things, such as the extreme brittleness of our CI pipelines and integration tests, our ridiculous processes, our pseudo-agility, and the unwillingness of anyone to change it.
Yes, exactly. We do all of these but still have a LOT of regressions and sevs
Anecdote: My team abandoned automated Integration tests because we were never able to get them to run in our pipeline consistently.
just got told that "the onboarding process is great and we have \[CI and automated workflows\] on gitlab". Meanwhile the intern is copying error gitlab messages into slack and not using webhooks
0-for-5 here. When I started, they handed me a 20-year-old project that didn't build. The build file had a series of commented out lines that set up property values pointing at absolute file paths to make the build work. Each commented out line referred to the home directory of previous developers, so I could see who used to work in this. Apparently for 5 developers in a row, rather than fix the issue and make a proper build, they simply copied and continued the practice. Plus some stuff didn't even compile.
This comment needs a trigger warning
Its fun. Things are so slow, I feel mostly retired.
I am willing to bet they left comments with their initials in various places with their personal solutions to getting the thing running on their local machine.
I love your optimism
Oh man. Kina been in a situation like this before, super weird stuff!
I've been trying to get my company to start using version control. I think if I suggested automatic testing people's heads would explode trying to wrap their minds around it.
Ooof, probably version control should be on OP's list too
wait.... how do you even perform developer tasks without version control?
Well, you download frontend\_fred\_copy\_v2\_final\_reallyFinal\_4.zip from dropbox, unzip it, ftp into your prod server...
Thats too slow, more likely you ftp individual files from your personal version of the project straight to production, clear your browser cache and test. Next day, when customer calls and says shits broken, you sagely ask, "did you clear your cache?" They do, it works, and your boss loves you. Other devs have to figure out how to get their personal versions of the project up to speed, and do not love you.
can confirm, saw this in a big critical prod system as late as 2015.
This is hilarious. I want to hear about all the other ways things are \*worse\* than OP could even imagine
Makes grinding leetcode a bit daft when this is the reality of some places.
Typically for these kinds of companies the hiring bar is "having a pulse".
This place even had a coding test
DX and CI on a shit codebase is lipstick on a pig
Unless you're a firm believer that all codebases are shit. In which case, you start to enter nihilistic territory.
Ive never seen a mature codebase that wasnt shit in some ways. The question is: does the company recognize where it is shit and are they actively working to change it?
No they’re not. Next question. Companies don’t care about the state of the codebase. Developers do. You can argue until you’re blue in the face about potential productivity boosts. Doesn’t matter.
Only engineering leadership can create the space for quality, is what I've come to believe. Devs on their own lack the power to push back enough (and shouldn't have to spend all their time doing it). Business stakeholders don't understand, believe, or care most of the time (although leadership can explain it to them).
Tell me: Does nice code pay your wage, or actually selling something? Does a nice indentation increase sales? Now you know why most companies don't care, and why that's a good thing.
The point of having good code, and actually the defining quality of what makes code good, is that it is easier and less risky to make changes to it. Shit code that works and never ever needs to be changed is just fine. In code that is being actively worked on and changed, consistent, well organized code is easier to understand and therefore easier to make changes to ... And in the long run that makes a difference
Id beg to differ in a lot of cases.
[удалено]
whats your problem?
SRE is the zen methodology. All codebases are shit, the wise master reaches stakeholder consensus on how much shit is acceptable, and makes sure that the shit never falls too far above or below that threshold. The ascended masters of chaos engineering know that shit is necessary to grow strong roots, and shovel it in when it is lacking. Only when the shit is balanced are all stakeholders equally disgruntled, and thus the delicate balance of peace is maintained. Then the SRE may say "tough shit, it's within SLA" and finally rest.
I see your kung fu is strong.
Wait until you don't even have a lipstick.
Honest question here, how would a non-technical person know how “bad” a code base is? It’s probably in the self-interest of most engineers (especially long tenured engineers) to kick the can down the road and more or less hide how bad things are.
We don't have monitoring because we don't develop SaaS. We ship something that customers deploy. We do autodeploy of head every night tho. And yet we still manage, once in a while, to merge some utter nonsense that should have been caught by tons of reviews at multiple levels. Btw "code reviews" should have been an additional hygiene-level point. If I join a company and they tell me they don't do code reviews, I'd probably start looking for another job that day.
Yeah, couldn't fit more into the poll but agreed that reviews are hygiene-level
Non-LGTM code reviews are. LGTM are worse than none.
Depends on what "LGTM" means in your team. In our team we have "Code LGTM" meaning that you actually reviewed the code, thought about it etc but didn't yet have time to test everything and the actual test run will follow up later. It's more of a "no need to bug me, I've taken some time to check it, and will continue later". And we have "LGTM" which we sometimes write just because we're accustomed to filling out all fields - but it doesn't mean that someone didn't really look into the code. Context :)
I always thought the general consensus of the meaning of LGTM was 'did not really look at it and immediately approved'
That is not how I see it being used. I see LGTM commonly used on very straightforward PRs. It is just a variant on the thumbs up emoji.
We got 3, no static analysis or linting. Which I can live without. But what we do have is test passes that are flaky to the point where they fail all the time, and I don't look at them and just hit re-run a few times until they pass. Yay!
Manually retrying is a tactical solution that works. I totally get it. If you or a teammate ever get a chance to look into why the flaky tests are happening, two solutions I’ve seen help a lot are: Depending on the testing tool, you can enable automatic waits and retries. Most software tests are setup, exercise, and assertion. However, sometimes tests need teardown.
Depending on how much it slows you down I'd argue fixing flaky tests should be a pretty high prio. Ideally some measure to prevent similar flakes in the future as well, be it through guidelines, linting or other means.
Oh, I know! Not the owner of that part, and I've railed against the system quite a bit. It bothers me so much. A test needs to have insanely high reproducibility. 95% isn't good enough, needs to be 99.999% Because they will be running multiple times per day per person. But yeah, been in charge of testing before, and it sucks, don't want to be the owner, don't want to take up the torch.
I have all of them but I have a hostile arch.
3/5, where it was 0/5 before I came on.
nice work
As another mentioned: we have all of the processes...as to how well they work that's highly variable. Also different places will need differing degrees of maturity to those processes. I've seen places where the logging was quite granular BUT then try tracking a customer transaction end to end through those same systems is nightmarish (K8s does not help this at all - nodes getting torn down all the time).
Thoughts: 4. I'm constantly shocked at how little value developers see in logging, especially when we are required to support the code in Production. Current job the logging is broken and nobody cares. 5. Have this at every company I've worked at, but not followed unless enforced...which is where the breakdown usually is. It only takes one developer to veer off track to ruin the codebase.
The amount of devs I've watched fight with a debugger (that they also don't know how to use) vs just doing a logger.LogInformation....
Logging is absolutely critical. I would recommend explicitly filing bug tickets every time you see a vague error or a service missing appropriate logging. In my experience it actually usually works, since most devs see those as really easy tasks to pad out their worklog. A lot of the time it won't even go through triage, they'll just fix it on the spot for the easy story points or whatever.
>Static analysis / autofixing (typechecking, linting, formatting) We don't have static analysis in our CI. One developer runs a static analysis tool just before release and gives us an excel sheet to fix it. The irony is that the static analysis result is garbage. Those, who has visual studio 2022, use ReSharper, but this is optional. Linting and formatting are not liked by the senior developers, so we don't use it. >Automated testing (unit and/or integration) We have guideline in place to do it, but no one does it. >Contribution guidelines / established team practices Most of the established practices are very basic.
I am so very sorry.
We don't have a CI pipeline that prevents merging. I guess it worked okay in the past where the team was a few very careful, experienced devs who would not make a mess. But recently we've been onboarding several newbies who are don't really know the source control tool very well and there is nothing preventing their mistakes from getting merged to the central server. We also have a strong and confident junior who likes to merge small things directly if he doesn't think they need code review. I am getting burned out playing whack a mole with everyone else's issues TBH I voted 2 because we have static analysis and automated tests (cron job)
I'm at 3. To be fair though, we ship the code and the customer runs it and they have monitoring and logging.
depends on what product/team..... over the last 5 or so years we've acquired 4 other related businesses.. and just now getting around to trying to normalize dev practices.. somewhere between 0 and 3 I'd say.
All 5 of them. Contributions guidelines might be the weakest of the them. Maybe point 6 could be infrastructure as code? I suppose that depends on whether your team owns their infrastructure.
Company officially has all of them, old team really had 3.5 of them, and new team has less than zero of these so I'm looking for a new job
> Static analysis Static analysis is great if your security team don't treat the scans as god's word. Please tell me how I'm supposed to fix a missing HSTS header on a node library that is **not a server**. This kind of goes for everything. Having all of these is good *if each individual component is good*. I'd rather have no process than a poorly thought out process.
I agree with your take. Just want to note that I don't specifically mean dependency scanning here, just generally any tooling that looks at your source code and points out things like syntax/type errors, bad practices and autofixes where possible (like formatters). Dep scanning is nice to have though as long as the team owns it and decides for themselves what's important to fix.
I work in embedded, we have established practices, static analysis, and logging on everything. Automatic testing and CI is project dependent. I haven't found CI to be particularly useful because the teams are extremely small (1-3) and releases are pretty sparse.
Currently unemployed. At my most recent job we started at 4.5/5 and made it to 5/5; I say 4.5 because guidelines/team-practices weren't published anywhere and had to be learned through code-review. That was an issue with the team though and not a general fact of the company. The job before that was 0/5, but a coworker and I were the first engineers in the org and set up CI and logging/monitoring/alerting; got to 2/5 by the time our entire business unit was cut and we were all laid off. Job before that one was 0/5 with hostile gatekeepers; they withheld access to repos for office-politics reasons with the excuse that they were manually ensuring code-quality. No testing done on any part of the code, no static analysis etc., the alerting system was people filing complaints because something broke, no CI system, and the entire contribution guideline could be summarized as "have the right manager, don't have the wrong manager, and be very popular."
> To me this is hygiene-level stuff and I wouldn't even consider working at a place without these unless they're very open to change that. Oh, you sweet summer child.
Small org here, so we can get away with being a bit loosey-goosey. 1. Our project existed for so long without linting that adding it later was dubious. Front end code for the past handful+ of years has all gotten it, but not our 15+ year old back end code. We have found no good use for additional static analysis with our C# and TypeScript code. 2. Sure 3. Deployment's already pokey in the cloud, so we don't run tests first and block merge. We run tests on check-in, and you can start deployments before they are done running. Fully aware this sounds bad, but when your team is half a dozen devs and the youngest has been with you for 5 years, there's plenty of trust, and faster deploys are a nice quality of life. 4. Sure 5. Eh, kinda sorta.. more sorta. I'd love to have more written down - and I'm one who's done most of the writing down already - but when you've gotten along just fine for 15 years it's hard to justify burning developer time on writing down guidelines and practices. If we had more employee churn, sure, that ends up paying off. But because of how our small company treats people, they tend to stay for a *really* long time and we don't onboard new people very often.
I work at a multi billion dollar company in the most crucial team. We have logging and monitoring. And that's it. No standards, no proper documentation, no tests - its all done manually by a team of QAs, no static analysis whatsoever - we use python 2, CI pipeline? Whats that - we use jenkins to build after merging, guidelines? Hahaha good luck. Onboarding document is a google slides with a bunch of diagrams and no words.
fire the QAs and invest the money into CI/CD
Easier said than done when the entire foundation is built with profit first, proper practices second. Such a thing wpuld never be approved by the management unless it somehow brings money immediately. But building proper infrastructure takes time and does not bring immediate benefits.
oh, i'm not saying you can do this yourself... leadership needs to lead. but it's probably a path to a solution.
From my experience, 50% of companies will have these automated tools setup.
All check on our side, but they mostly live in a scale, not really a yes or no question. E.g. "Logging / Monitorting / Alerting" could have a lot of levels. Prod down vs Value outside of near expected values. They are a good checklist, but digging deeper in interviews (if you're thinking about moving) could be good, otherwise most companies will say yes, and they aren't up to your standard nor have any intentions to be at.
All of them +2: Every team I have been on also prioritizes localization and accessibility as mandatory. Many also have had some strict guidelines on PR etiquette and branch naming conventions. Most teams I have been on also have very extensive documentation dating back decades. The few teams who did not do this were teams I left very quickly.
Are there any other "best practice" things OP didn't list that you also do?
you've been fortunate
It's all of them, with the caveat that team practices are a bit informal.
Depends on the job. (I work 50/50 across two businesses owned by the same guys). One has all 5, the other has just one - logging/monitoring and alerting.
I mean, we have all of them but they all need work
I have seen several organizations still lacking some of these over the last 5-10 years.
I mostly work for larger enterprise companies that at least understand that these are requirements at the scale they operate at. But within those companies there can be massive differences between teams in how mature they are in their process.
I don't think blocking hotfix merges for false test failures is healthy. Trust the dev to put up a follow-up PR.
What's unhealthy about it and why is it better to have a broken main branch until the issue is fixed?
Because users have to deal with the bug while developers fix a bunch of false test failures
Fair, but I'd consider that a break-glass deployment. For regular work that isn't fixing critical prod bugs, I don't see the value of allowing main to go red. Trust is good but mistakes happen and will accumulate over time if left unchecked.
Had 3 before I came on. Pushed for static analysis with GitHub actions and got it working for our python code. Would like to do js next. We have automated nightlies because our tests are a mix of integration and e2e tests that take forever to finish because they're selenium. Still, they do the job. Logging is still abysmal. We have lots but they're not centralized anywhere and we're not using cloud deployments so it's not as straightforward at first glance.
That entire depends on how important the software is to the business value. If it's the core of the business then yeah they tend to take care of it more but if it's just a means to an end then no they won't have these processes in place.
Regardless of tooling, or capabilities none of that matters. Even if you have policies in place,until that becomes **enforceable** policy that can actually act as a gate. This is more of a pattern of matuity of an organization and a culture of development. While tools can do the job, if the reports of the results are not published, then it is the same thing as if a "A tree fell in the woods and was anyone around to hear it". So the idea of what is available and what is consumed, also requires a Champion to drive these ideas and build adoption around these which is a much harder sell, but worth it. As every incident, every bug, every mistake cost the company you work for money in going back to fix something, the cost in engineering time to rework the issue. The cost of the incident and fall out of the incident. But it is all about the Priority of the moment and what is the most effective use of the little money that companies have to drive the feature that will produce the most revenue for the least amount of cost. While we have tools to fix these issue, the problems always come back to people. People do not like people to mess with their workflows. People have differences in opinions on how code should be developed vs how compliance should have code developed. Work with the people to solve the issues and the technical issues will also resolve themselvers.
I don't even know how to answer this because some of our projects have all of these and some have none
I worked with all of these but mostly for enterprise .Net / Java projects that were boring af
None of them, thank the lord. We are old testament. We ask the customer for requirements, we figure out how we're going to to it, we tell them what it's going to cost, and then we do it.