State of IT
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 — 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 that the Trunk-based development is 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:
Originally published at www.multunus.com.