Stop Pretending You Do Continuous Integration – Here’s What It Really Means

Having a build pipeline doesn’t mean you do CI/CD

Jan 18, 2025

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.

At some point, I felt my developer license was going to be revoked.

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: