Wednesday, 29 April 2015

DevOps - The Opening Game

In the game of chess, a beginner level player always benefit from the "book moves" in the opening game. These are recognised sequence of initial moves which are standardised in a reference work (such as the Encyclopedia of Chess). The opening game will allow the player to develop his game well and to control the centre of the chessboard to take further advantage.

In this blog, I will discuss about some "book moves" in the opening game of DevOps which I learnt while setting up the Continuous Delivery system for a large scale eCommerce project with world wide deployments.


Continuous Delivery - Build Pipeline








The continuous delivery build pipeline as shown above will be familiar to all who are doing CD/DevOps. I will discuss some good practises in each of the three stages starting with Build


Build


1. Commit often, Merge daily


"We rework much after each merge review", many of my team members had this as an improvement point at the end of our first sprint. This was followed by a spirited discussion about how they can preempt the merge review.

I asked them to fill up the following;
"To have your merge reviews early and often, you should at least __________".

Sure enough, they found out that the answer was to merge early and often.

Developers should be encouraged to commit their changes often. Each commit should trigger a local build (also known as private build) which should compile the code (if required) and run the minimal set of static checks (checkstyle, PMD etc.). This build should give feedback almost immediately.

The commits in the development branch should be merged to the master daily. A Version Build runs on the code in the master at least once daily. The Version Build should run a smoke test suite besides the static checks. 

2. Keep static checks clean


I coached a team for deploying their CI. Their build script made me rather curious:

C:\> buildXYZ controller 12842

The magic number turned out to be the number of open static errors that their code already have. Their build script was intended to fail the build if any more static errors were added.

Their intent was good, to leave the code a little bit better than how it was. 
The implementation, however, had 2 problems.

(i) This was a rather dumb way of using the tool. Static errors are to be acted upon. They are often clues to potential defects. Treating them as metrics will not achieve this.

(ii) Since the number would change in each sprint (reduce of course!), the team members used to run the build script in local build as

C:\> buildXYZ controller 50000

since they could not intuitively use the limit. This limited the benefits of the static check from the local build.

Note: Folks at Coverity, a widely used code static analyser tool, mentions in their blog "A few billion lines of code later" ( http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext ) other collateral damages happening out of this approach. 

This could be avoided by using the principle of Separation of Concerns. All the popular programming languages today render themselves to be modular, where a function extension can be implemented in a new file or class. We can configure our static builds such that there are zero errors on these extensions.

See my next blog for some good practises in the Test stage of the build pipeline.