Stop Pretending You Do Continuous Integration – Here’s What It Really Means
Having a build pipeline doesn’t mean you do CI/CD
Coming from a freelancing background where my chance of survival on the market increased as I could do more things for my clients, it wasn’t even a question of whether I could do CI/CD for them. Of course!
This inspired the following post, which sparked quite some debate.
I was wrong.
CI/CD involves more than just the build pipeline, creating artifacts, and deploying a new version.
I’ll give you a short version of what I learned, this time focusing on the CI part.
Let me know if, after this article, you realize you don’t really do CI, so I’m not alone. 😄
What is Continuous Integration
Continuous Integration is the process of frequently merging code changes from multiple developers into a central repository (i.e., the main branch), where they are checked for correctness.
What is continuous integration? - Atlassian
Continuous integration - Wikipedia
Continuous Integration - Martin Fowler
We all do this, right?
Well, I don’t think so, so here are a couple of examples of what is not CI.
What isn’t Continuous Integration
Long-Running Feature Branches
Some teams use feature branches that last for days or weeks. This is not Continuous Integration because:
Changes are not integrated into the mainline frequently (at least daily)
Developers work on an increasingly outdated version of the codebase
The risk of merge conflicts and integration problems increases over time
Feedback on how changes interact with other developers’ work is delayed
In Martin Fowler’s article, this practice is called “Semi-integration,” which is commonly mistaken for true Continuous Integration.
Most organizations I worked with used this practice. Until now, I was referring to this as CI as well.
Manual Build Process
This doesn’t rule out the use of true Continuous Integration, but teams that rely on manually building the software would likely have trouble keeping up with the frequency of changes in a true CI process. Furthermore, a manual build process might be followed with manual testing, which rules out Continuous Integration.
Manual testing is too slow to cope with the frequency of change.
This approach also:
Slows down the feedback loop
Increases the risk of human error
Makes it difficult to maintain a consistently healthy mainline
Neglecting Broken Builds
If a team allows the mainline build to remain broken for extended periods, they are not following Continuous Integration practices. This:
Prevents other team members from integrating their changes
Reduces confidence in the codebase
Delays the detection and resolution of integration issues
Incomplete Automated Testing
Teams that integrate frequently but lack comprehensive automated tests are not fully practicing Continuous Integration. Without self-testing code:
The health of the mainline cannot be reliably verified
Developers lack the confidence to integrate changes frequently
Integration problems may go undetected until later stages
Conclusion
Most of you already have automated builds and tests because they’re freely available. However, without frequently merging your changes back to the mainline, you’re not practicing true Continuous Integration.
So, while the tools I mentioned in my original post are all part of the build pipeline, which is important for the automation aspect, it’s only part of the story. As Raimund put it:
My main takeaway is that pipelines don’t make the integration continuous; developers do. It’s more like a team culture to write code that you can integrate back at least daily into the mainline so that the app remains in the correct state.
But I’m curious to hear about your team.
Do you practice true Continuous Integration?
📰 Weekly shoutout
📣 Share
There’s no easier way to help this newsletter grow than by sharing it with the world. If you liked it, found something helpful, or you know someone who knows someone to whom this could be helpful, share it:
🏆 Subscribe
Actually, there’s one easier thing you can do to grow and help grow: subscribe to this newsletter. I’ll keep putting in the work and distilling what I learn/learned as a software engineer/consultant. Simply sign up here:
Great article Akos. It makes the process of CI and also the misconceptions around it quite clear.
Also, thanks for the mention!
Thanks for the shout-out Akos!
CI is one of the keys for high performance teams s for having a great prt.
Build small -> release to customer -> get feedback -> adjust.
Without that, and in a quick timing, you are doomed!
Great job!