State of ITleena
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:
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]
Loosely coupled architecture
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: