I'm currently re-reading the book Accelerate, the science behind devops where a list of technical practices are found to contribute to continuous delivery, which in turn contribute to organisational performance - meaning roughly that they increase revenue, market share etc.
This post is meant both as a reminder to myself and as a way to condense the essence of the findings. I particularly put all the findings that were surprising either to the authors or to me.
 |
| Photo by Isaac Wendland on Unsplash |
Practices
The following technical practices were found to be significant in predicting high Software Delivery Performance that in turn predicts Organisational Performance.
Version control
All teams have version control for the code. However having additionally
- system configuration
- build and deploy scripts
Test automation
Having automated tests are correlated with high performance. but only if they're reliable (not flaky). Otherwise having automated test is not correlated to high performance.
Having tests primarily written and maintained by a QA team or an outsourced party is not correlated to high performance.
I.e better have tests written and maintained by developers
Trunk based development
Teams that did well practiced Trunk Based Development of some sort. The best performing teams had fewer than three active branches at any time and branches were merged at least daily.
Using feature branching or git-flow was negatively correlated to performance. However the authors acknowledge that if you merge your branches at least daily the difference may be negligible. They also acknowledge that git-flow is a good fit for open source community projects.
Architecture
High perf is possible with all kinds of systems, provided that the systems, and the teams, are loosely coupled. That is high performing teams were found in legacy systems as well as green field projects.
Highly correlated with high performance are the ability to
- Do most of the testing without integration with other platforms.
- Deploy without synchronisation with other teams
They also found the surprising fact that for high performing teams the number of deploys per developer increased with more devs. The inverse was true for poor performers. This stresses the importance of loosely coupled architecture.
Choice of tools
Being able to choose the best tools for the job contributes to performance and hence is found to outweigh the value from rationalisation by mandating tools within an organisation.
They mention a few exceptions to this rule.
They suggest Architecture as a service, where system teams work as service providers to other teams, as a good way to strike a balance. The feature teams ultimately retain free choice of what is best for them.
Infosec
Teams that integrate infosec in the design and development, as opposed by auditing after the fact, spend 50% less time fixing security problems. I.e infosec teams should be involved in design and assist in demos regularly.
Info sec teams, just as architectes, can provide tools that are easy-to-consume, pre-approved libraries, packages, toolchains to make it easy for teams to develop secure applications.
Conclusion
There are a lot more in the book than a list of technical practices, it's well worth a read. I hope you found this condensed resume either useful in itself or an inspiration to read the book :)
