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 folks around who can do things as said, but there are very few special ones who are decision makers. What makes later ones 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 the said philosophy, this 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 into boring theory, but I will wrap it in simple words. It’s an automated process which continuously builds your project and deploys it.
Let’s try to answer our question which we should be bothered about it, i.e., "why I should go for it".
There are many drivers for adopting Continuous integration, build and deployment - I 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 a better position to make a decision in this regard.
I will refer to 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 have 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, the answer is CIBD adoption.
Driver 2: Monitor Glitches and Rectify as they are Discovered
Glitches refers to build errors, broken links or any other horrifying error. Glitches give a very hard time, the first challenge is to find them and the bigger one is to resolve them. Especially in less frequent build requirement scenario. In such cases, after ages when integrator starts integrating all modules, he/she discovers lot of fatal issues in it and then everything will pile up to an extent which results into postponing delivery. Sometimes, it creates a critical business risk for the 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, you 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 highlighted for misdeeds and face the exaggerated blame, makes them extra cautious regarding code and unit testing before committing anything on the server. This rectifies a 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 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 many of them are seriously “Yes” in your case and if the majority are, then CIBD is the way to go.
