State of IT

July 5, 2017

Continuing with my earlier post about Operability, but this one focussing more on the State of DevOps report. State of DevOps report is a report published by Puppet every year along with Nicole Forsgren, Jez Humble, Gene Kim, Nigel Kersten by analysing the results of the survey they conduct. They received over 27,000 responses over the last six years and found clear evidence that DevOps practices yield remarkable results for IT teams and organisations.

The report says by focussing on Continuous Flow of delivering value to the customers, the performance i.e. the individual, the team and the organisation, improves significantly. And this is done by optimising:

• Deployment Frequency

• Lead time [from commit to production]

• Meantime to Recovery (MTTR)

• Change Failure Rate

And the key practices to be followed for improving the above are:

• High level of automation [build, test and deploy automations]

• Trunk based development

• Loosely coupled architecture

• Lean product development [working in small batches with tight feedback cycle]

What is interesting is Trunk based development, the most controversial of the above. The authors of the DevOps Handbook mentioned the below in the book:

Trunk based development was highlighted in the report for last few years as a key differentiator between the high performing and low performing teams.

Short-lived branches are aligned with Trunk based development because the focus is on small batches. But how short is Short-lived? The research shows that branches_ living beyond a day_ slows down the team’s integration and deployment flow and that’s a warning sign to look at the team’s practices and architecture.

Tapabrata Pal, Director of Engineering at Capital One, talks about how changing the Branching strategy along with automating the pipeline helped them increase the deployments by 20%.

Sam Newman in his talk Feature Branches and Toggles in a post Github world mentions the formulae for calculating the pain of merging:

He also talks about the Pull Request model popularised by Github and why it makes sense for Open Source and how it becomes a hindrance to Continuous Flow.

Fundamentally the Continuous Flow can be built if the team has clarity for whom they are building the products for and optimising for happiness.

If you want to know more, please refer the following on the same topic:

• The Death of Continuous Integration

• Continuous Integration Certification

• Feature Branching is Evil

• Trunk based development

• Long living Feature Branches - An Anti Pattern

• Merge hells!! Feature Toggles to the rescue

• GitHub Workflow vs Mainline development