Continuous Integration: Why and How?

Continuous Integration: Why and How?

In an recent interview alongside Ian, we stumbled across a discussion on cost and benefit  trade off of Continuous Integration (CI) and how it could be implemented. (Oh and by the way, I am happy to report that the interviewee is now an Appnovator :))

It is interesting how the concept of CI/CD has been there for over a quarter of a century but lots of businesses are still struggling to implement it or are not even considering it!

CI is the practices of merging development code in a frequent and continuous manner, from what used to be once a week or even once every few months to sometimes several times a day. Aligning with the principles of DevOps, it is usually highly automated, it shortens feedback loops, and over the long term, it encourages teams to think of systems holistically. (I’m sure a quick use of your Google machine will give you many other info and definitions but that’s how Ian and I tried to summarise it in two sentences.)

*If you are already sold, skip to the How.

The Why

Here are some of the excuses we have heard:

“It takes too long to set it up! And we just want to get to development! We just don’t have time!”

“It wouldn’t work with our technologies!”

“Our environment is too complex.”

“It’s just too hard!”

“It’s not my job.”

“We have been doing fine for 15 years, why change now?”

“If it’s not broken don’t fix it!”

Sure, they are valid points (sometimes), and who are we to disagree? You know your business best. But let’s have a look at the RONI - Risk of Not Investing. If we are not doing CI, then we are integrating weeks or months after code has been developed, this can lead to a highly unpredictable hardening cost.

Your unit test might cover bugs for individual components but likely not for the whole system (holistic thinking guys!)  This also raises the question of when you would be running your integration tests if you aren’t continuously integrating. Unit tests and integration tests are different things, and integration tests are necessary to ensure that all components work together.  If your testing is not happening all the time, you will also miss the opportunity to fix issues as they occur, instead depending on long periods of bug-fixing to rectify numerous issues. This could be crippling.

The simple fact is that CI shortens the time between development and integration/regression testing. This means that developers find out about issues when they are still fresh, easier to fix, and have less technical debt attached to them. Not only does this save time, but it also saves money because a bug that is fixed right away will impact the schedule less dramatically than one that is discovered right before release. It also means that fewer issues make it to production. The faster feedback loop reduces cost, improves predictability, and makes everyone happier. Developers don’t want to spend time fixing bugs; they want to improve things.  Developers’ confidence improves dramatically with the increased assurance that comes along with continuous integration. Confidence leads to enjoyment and improved morale.

This, in turn, also comes with inherent performance improvements.    

“So you are saying, CI minimises (and if done well, eliminates) the hardening period and potential delays; it decreases bugs therefore increases the quality; and it makes my developers works more effectively and happier? Where do I sign up?

The How

Well here’s one we prepared earlier:

Next time, we will run through the How in more details and maybe talk more about how it paths the way for CD.

What do you think? Still not sold? We would love to hear your take on CI!