Keep your private branch green
Continuous Integration has been around for a while now and the tools around it with (close to) zero setup time as well as the processes have evolved a lot.
To bring everyone on the same page: When I talk about Continuous Integration (CI) in this article, I am talking about the practice of automating your quality tests including static code analysis and code coverage, integrating changes in small batches and receiving the state of your quality tests automatically, or in other words, keeping your branch green.
While nobody would even start a discussion these days why you should keep your master branch green, I am arguing that you should take care of your private branch in a similar manner when you are following a branch-based development process.
Why?
I was never a big fan of Jenkins except that it was better to have Jenkins than not having any CI system at all. However, what I have always liked about Jenkins is their logo. In my opinion, their logo perfectly captures the core of CI and the why behind keeping your private branch green:
CI is your personal as well as your team’s servant. Let’s explore 4 ways the CI can serve you.
Fast Feedback
Keeping your CI green gives you feedback about the state of the software in your development branch. Of course, you could run your automated quality tests locally, but running your tests locally is consuming too much time. You want somebody else to do it who can potentially do it faster and who can do it while you’re already proceeding. So run your affected unit tests locally, commit early and often and let the CI take care of the rest.
When I am in programming mode, I usually commit every 5–15 minutes. After committing I take a quick look at the CI and check if everything is still green. If not, I will fix it and only after fixing the issue, I will continue with the problem at hand. (To keep the git history clean and not have too many commits, you can squash merge.)
Avoid Collecting Mud
All of us have been there and I’ve come to the conclusion it’s a little bit like the hot stove. You have to get burned yourself.
You are in deep programming mode tackling the problem at hand and you notice that you have broken your build elsewhere in the code. You are thinking:
That is not important right now. I can fix this later.
This even “works out” in most of the cases even though you are already saying goodbye to fast feedback and this way of working will make you slower.
However, sometimes sh*t hits the fan and you’re collecting mud (quality issues) all along the way. Because you start ignoring the CI (it’s red anyway) and you only realize in the end that you’ve broken much more than you thought. We all know how painful it will be to clean up the mess now.
Easier Team Takeover
Let’s assume you end up in exactly the mentioned situation of having collected a lot of quality issues on the way and it’s the end of the day. You’re telling to yourself, I will fix this first thing tomorrow morning. Best case scenario you wake up the next day, it will take you quite some time to get all necessary information back into your working memory and you fix all the issues.
Worst-case scenario: You wake up the next day feeling sick and a colleague of you will have to take over because the story needs to be finished. Would you happily take over a red branch with obvious quality issues from a colleague of yours?
Avoid “It Runs On My Machine”
It’s our favorite excuse when somebody reports a bug. And for a reason. Very often it does run well on our own machines. However, very often it does not run on other machines and your CI is the first guard to watch out that it potentially also works on other machines. And as said before, you want to have this feedback as early as possible to not having to clean up in the very end.
Servus CI
In Bavaria and many other regions around southern Germany, Servus is a very common greeting and it originally translates to
Your most humble servant.
Receiving fast feedback, avoiding collecting mud on the way, making team takeover easier and not falling into the developer trap that it only runs on your machine are my top 4 reasons to make CI my most humble servant.
But of course, this only works, when your branch is green so please keep it that way! 😀 ✅
Dominik is a co-founder and CTO of Chatchamp. He is enthusiastic about software engineering and has worked for Siemens, IBM, and BMW before founding his own company.
Along the way, he is curating a list of inspirational posts, books and videos on his homepage Inspirations for Life.
