Continuous integration is about confronting your risk. It’s about giving rapid feedback and responding to problems that you may encounter in your development environment.
If you’re Agile, you know one principle is adaptation. It’s not about sticking to the plan; it’s about exposing and responding to change in your development cycle. This is why the principles of continuous integration and Agile walk hand in hand.
Delaying the inevitable risk of code integration doesn’t mean the risk will disappear. Each line of code you change is a risk. Each commit you do is a risk. You can’t avoid the risk by putting it off. Just like anything, if you were going to bottle up all of that risk, let it ferment for a few months and open it later… I’m pretty sure you wouldn’t want to drink the whole bottle in one gulp. It really only takes one sip to know the concoction is bad.
Continuous Perfection is one of the reasons we bottle up the risk. Let me give you an example.
We set up continuous build on trunk, we encourage our developers to integrate early and often, life is good…. until the day of the broken build.
If it’s broken for even a day, panic ensues, we’ve issued blame to developers for something they should not be responsible for, a stoppage in work for organization. People will feel rushed to resolve issues, the QA team will stop testing, and our release engineer will struggle to roll back code. Essentially, people will be running around like chickens with their heads cut off.
Our management teams do what they do best, they listen to the release team, QA team and the dev team. “Joe Developer broke the build, it’s his fault that we can’t work today”.
When did the broken build become such a big deal?
This scenario may repeat itself, over the course of several weeks our mangers will react, and start asking developers to put in process to avoid breaking the build. Our teams will start to feel that their code must be perfect before they commit. This problem is called Continuous Perfection, it’s the idea that the code must be perfect before it’s committed to the repository.
And doesn’t this seem to work against the principles of continuous integration? The idea here was that we integrate early and often to avoid Integration Hell and the Big Bang merge. We want to confront and work through our problems right now. But now we’ve started to go back to what we do naturally. Isolate changes, put off the inevitable and work off of our private branches. Our developers do local builds to make sure the builds work correctly, and jump through hoops to avoid committing to early in fear of being blamed. We are back where we started, with a huge merge at the end of the project that could fail everything. We bottled up all our risk, and ended up in a more dangerous place then we intended.
But what can we do to solve this problem ? To be continued…