As annoying as it is when someone else breaks the CI pipeline on me, it is utterly invaluable for keeping the vast majority of commits from being able to break other people (and from you breaking others). I can’t imagine not having some form of CI to preventing merging bad code.
Hah, or my current one. Before we had CI you just directly committed to master (on SVN). It was incredible how unstable our build was. It broke basically everyday. Then one of the senior back end guys got promoted to architect and revamped the whole thing. Probably saved the company tens of millions dollars in man hours, at the very least.
Even better is when you restrict merges to trunk/main/master/develop (or whatever you call it) to only happen from the CI bot *after all tests (including builds for all supported platforms) pass. Nobody else breaks the CI pipiline, because breaking changes just don’t merge. The CI pipeline can test itself!
As annoying as it is when someone else breaks the CI pipeline on me, it is utterly invaluable for keeping the vast majority of commits from being able to break other people (and from you breaking others). I can’t imagine not having some form of CI to preventing merging bad code.
You should have seen my last job.
Hah, or my current one. Before we had CI you just directly committed to master (on SVN). It was incredible how unstable our build was. It broke basically everyday. Then one of the senior back end guys got promoted to architect and revamped the whole thing. Probably saved the company tens of millions dollars in man hours, at the very least.
Even better is when you restrict merges to trunk/main/master/develop (or whatever you call it) to only happen from the CI bot *after all tests (including builds for all supported platforms) pass. Nobody else breaks the CI pipiline, because breaking changes just don’t merge. The CI pipeline can test itself!
I often wonder if there isn’t some goodharty kind of local-maximum trap hiding in this…