Also using Azure DevOps and it is indeed very well structured.
As for CI/CD differences: how many commits can actually affect code and infrastructure? I think this is part of the engineering problem at the end of the day.
We have a large Java monolith application. Builds ran for 30 minutes. Then we said let's only run the unit tests and critical smoke tests. The build time went down to 7 minutes ... on 12 CPU and 32 GB of RAM build slaves :) There's always a way.
> There's no need to as I mentioned that you're going to be hosting it somewhere during development anyway.
You will probably host 1 version which is infrastructure heavy and not very flexible. Take 10 developers working on the API. They all need to test their changes. Automatically if possible. Hosting external elements like the database and others is a pain eased by Docker.
nock will intercept http requests in the same node process it is used in. Here the test (and the mock) are in a different container and thus process. It won't catch them. Unless it is possible to actually spin up a server using nock and I've missed it? In which case I agree, custom code is not needed.
I've updated the sentence with "Here are the common objections one might have and a tentative solution" and extended the conclusion to say "TBD is not the only way to work"
Agree that feature flags count should not explode because you can never test all combinations. Feature toggles should drive the life span of a feature from start of development to "adopted and becomes the default" or "rejected and we scrap it all out". At the end of the day the number of feature toggles should remain relatively low.
Fair enough. You have a valid point on "your objections are not valid" is not the right tone. I'll edit to highlight that feature branches have their benefits in some cases. Thanks for reading!
k8s is open source, which is a different setup: you can't just merge in anything that comes in. In commercial projects though, even with a large team, you should be able to trust any team member to contribute to the main branch in the right way. Mistakes and errors should be caught by the CI build.
Getting from here to there probably requires a transition phase. In the long run though, if the time spared/lost waiting for PRs, developers context switching, resolving conflicts and dealing with errors (that will appear anyway) is invested into improving the quality and speed of automated tests, you end up in a much better place.
I'm not saying it's an easy thing, but in my opinion this is what development teams should strive for.
And now that I look at your question again: yes. If all 23 builds were green and one person merges, then it would trigger a build on the remaining 22. The thing being that you probably shouldn't have 23 PRs lying around (probably waiting for code review).
As for CI/CD differences: how many commits can actually affect code and infrastructure? I think this is part of the engineering problem at the end of the day.