The Continuous Integration ‘Blind Spot’
What if I told you that you are not ‘Really’ doing Continuous Integration by (still) doing Continuous Integration — Is this sounds like rubbish? — Or are you really became conscious thinking about it?
I would say, ‘Think’ about it for a moment. Yes, maybe it can be the case that you are pretending to do Continuous Integration but you are ‘not really’ leveraging your product from Continuous Integration. Let’s take a deep look inside — what actually Continuous Integration really looks like?
There are two blind spots to deal with here; the first is with our understanding and application of CI and the second one is derived from the first one by already making you clear about the hidden bugs and conflicts that lurks your work progress because you’ve incomplete vision of CI.
First, let’s figure out where we really been missing by taking a closer look at two of the lists.
‘I am really doing Continuous Integration’
Possibly, I am betting that on-first look you will be doing at least two of the points or could possibly all three:
- Check-in the code to a centralized source repository
- Automate Build & Test
- Always have a working build
Okay. Well, what about this one?
Here’s a more tailored (aka Continuous one) of the above list:
- Merge all changes to the trunk/main at least once per day
- Automate Build and Test the changes after every commit
- Repair broken builds of trunk/main within 10 minutes, while halting further commits until build is fixed again
Hello? Where are you looking? Have you started thinking about the second list? Hmm, it means you getting back towards the right track. Well, let’s take a closer look at what second list actually does mean.
For clear understanding and deeper reference, I am taking a snapshot from Martin Fowler’s Continuous Integration Certification. Here’s the look:
You can clearly see the difference of workflow i.e. automating builds and tests on every commit. The best outcome out of this practice is the ability to work and iterate over bugs, hotfixes, code-breaks, leaks, exceptional errors, etc. in a much more faster time. Instead of merging ‘bulk-sized’ batch into main-line/master at the end of week/sprint — doesn’t it sounds better to start believing into ‘small-sized’ batches and continuously improve the end-product overall?
Now, let’s take a more closer look at different workflows followed by different engineering teams of tech companies and startups.
Have a look at the (below) attached diagram. Can you see those big ‘Yellow’ circles or spots? Those are nothing no more newer than ‘Merge Conflicts’. Yes, you heard right ‘Merge Conflicts’. Now maybe you aren’t scared much (really?) or maybe you are scared of those Big Yellow circles. It tells how much time, effort, complexity and patience that conflict is going to take to make it finally resolved. The bigger the circle is — the bigger the time and effort it will take. Simple is that.
Now, let’s take a look at the (below) attached diagram. See those ‘Yellow Circles’ — I mean their size. They are relatively have now become more smaller in size — but how this happened or what caused to reduce the time and effort we will be going to put in solving a ‘Merge Hell’. That happened because we have committed smaller changes into main-line and pushed it by just solving a ‘minor’ conflict after pulling from the main-line and then successfully pushing it back to main-line. Look at those ‘small-sized’ incremental changes. This helped the team to continuously refactor the code with minimal time and effort and improve the product overall at the end.
Hopefully, it has helped you in clearing the understanding and the ground phenomenon behind Continuous Integration to make it actually work in the ‘right’ way. I guess, now it’s the time for relatively smaller tech industries and startups to start believing in incremental ‘small-sized’ batches rather than big-hecky and ‘bulk-sized batches’. If you are really serious and conscious about maintaining the health of your overall software and building an effective and highly productive engineering team, then difference would be no more harder to spot.
Cheers!
