I’m going to go out on a limb here (pun intended) and say that the purpose and benefit of continuous integration have to do with integrating our code continuously. That makes sense but I see so many teams use their CI systems to isolate their code in branches and prevent the code from being integrated with the rest of the system until the end of the project. We have a name for that. It’s called Waterfall.
Waterfall software development had many problems but perhaps the biggest one was integration. When we put off integration, there are more and more opportunities for things to go wrong and because problems can compound each other, it can be challenging to dig your way out. This is the danger of isolating code.
Git makes it easy and cheap to create branches. It’s a technological breakthrough but that doesn’t mean we should always use it. There are definite use cases for branches so I’m not saying we should never branch but I am saying that we should avoid long-lived branches because the goal of continuous integration is to integrate our code continuously.
I like to create experimental branches where I’m trying out an idea to see if it’ll work. These are short-lived branches that I integrate back into main very quickly, usually anywhere from a few hours to a few days. When I know what I want to build but I don’t yet want to expose it because it is incomplete then I used feature flags.
Perhaps the idea of feature flags is so simple that many developers are unaware of it but it is the recommended way of building a feature while integrating the code into the rest of the system. It’s a simple idea. Build the feature with the rest of the system but make it inaccessible to users while it’s being built. We can do that with a simple flag that we set for the feature while in development so it’s removed from the user interface but it still gets built with the rest of the system and so we can integrate while we are building.
Integrating code as we are building it is vitally important because the only way to have a true measure of our progress is when we integrate a feature within the rest of the system. Only when we integrate our code do we see if it will work in the context of everything else. This is why integration is so critical for reducing risks and giving us a true measure of our progress.
Computer systems are complex and the way to simplify integration is to do it all the time, do it when you only have one tiny little thing to integrate because if something goes wrong you’ll have a good idea of what that would be. As soon as we start to integrate multiple issues at a time the permutation and combination of things that could go wrong start to grow exponentially.
Developing software is risky. Not only is software development risky but it’s opaque to many management techniques because it’s not well understood. In order for something to be managed, it has to be seen and recognized. This is essentially what continuous integration does for us. It tells us the truth about the state of our system and so it’s an essential part of virtually every software development project.
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set here. The next seven blog posts are expanded versions of “Seven Strategies for Burning Down Risk”. You can find the original post here.
Previous Post: « Integrate Continuously
Next Post: Invest in Automated Tests »