"Continuous Integration" - Should I go for it?

Leave "How" for a moment. Think why you should adopt Continuous integration.

Let’s set the context of the article first. There are lot of doers around who can do things as said, but there are very few special ones who are decision makers. What makes later so special, it’s the way he-she thinks about stuffs around. They ask questions in their capacity and do self-research, they never rely blindly on things said by great ones, they challenge and doing so they achieve mastery in it and mold themselves into a decision maker.

Aligning with said philosophy, article will focus on "why I should go for it" than "How". Here "it" refers to "Continuous integration-build & deployment". I have added deployment explicitly in widely used term as I feel it’s a quite connected term.

I won’t go too much in boring theory, but for sake - will wrap it in simple words. It’s an automated process which continuously build your project and deploys it.

Let’s try to answer our question which we should be bothered of i.e. "why I should go for it".

There are many drivers for adopting Continuous integration, build and deployment - will visit them one-by-one. Don't think about “how” while reading this article. There are various online resources available which most of us are smart enough to utilize for that. Very few will feed you knowledge to decide whether it fits your scenario or not. At the end of this article, I am certain that many of you would be in better position to make decision in this regard.

I will refer Continuous integration - build and deployment as CIBD here onwards (yes I’m lazy :)

Driver 1: Minimize Efforts spent

Think of efforts spent by our poor integrator and deployment team. Whenever any release/patch has to be thrown, our poor folks has to spend their nights in office to achieve pity success. Real miserable pains are build time, finding-coordinating for errors fixes, unit testing, smoke test, testing team coordination, create-deploy deployment package & notify stake holder etc. Quite a long list. A mid-size (10k lines of code) web based application needs around least 2-3 person days of efforts for all listed activities for one iteration & it’s quite frequent. There is a serious need of automation, answer is CIBD adoption.

Driver 2: Monitor glitches and rectify as it discovered

Glitches refers to build errors, broken links or any other horrifying error. Glitches give a very hard time, first challenge is to find them and bigger one is to resolve them. Especially in less frequent build requirement scenario. In such cases, after ages when integrator starts integrating all modules, discovers lot of fatal issues in it and then everything will pile up to an extent which results into postponing delivery. Sometime, it creates a critical business risk for end client. To rectify this, CIBD is the solution .CIBD will continuously build your code chunk preferably with each code commit in source-control server and throws error if any glitches. Culprit (one chap from us) will be made to fix it. With CIBD will surely rectify 11th hour horror discovery and help us to play a smooth delivery. 

Driver 3: Sense of ownership with fear of misdeeds

With CIBD in place, a culprit can be caught very easily using source control commit log for an instance which made the build fail. This will embed a positive fear in team members mind - no one would want his/her name to be highlights for misdeeds and face the exaggerated blame, makes them extra cautious regarding code and unit testing before committing anything on server. This rectifies lot of rework.

Driver 4: Ancillary additions scope

To achieve wide scale automation, we can dope in few ancillary things like Static Code Analysis tool, Automated Unit Testing tools, Code Coverage Tools, Automated System Testing tools, Health Monitors, Configuration Management utilities. Adding these will make your overall process a resilient & adds further saving in time-effort-cost. 

Driver 5: Statistics

It’s the era of analytics - predictive, descriptive whatever any *tive. CIBD will give you stats of the build with success, failure ratios, and team based segregations whatever you think off, in very fancy charts. This will be seriously useful while flaunting reports to management.

Driver 6: Ancient ones - Code Coverage, Unit Testing blah blah blah...

And there are more to add which you will find in any CIBD article. Naming few ones here - code coverage, unit testing etc. I think they are self-explanatory – no explanation needed.

Finally, With these six drivers, post assertion against all six for your particular scenario see how much of them are seriously “Yes” in your case if majority are, then CIBD is the way to go.