Accelerate book cover

Accelerate: Building and Scaling High Performing Technology Organizations, by Nicole Fosgren, PhD Jez Humble, and Gene Kim

The science of lean software and DevOps

Review

Accelerate is grounded in research done by the three authors, its a report called the "State of DevOps" where they have been asking different engineering teams about how they are building and delivering software. 

It is split into three parts

  • What we found
  • The research
  • Transformation

During the book reading, I found that the part I was interested in was the first and the third part, as they contain concrete topics that can be reflected upon in my daily work. The research is a chapter describing how they did the report and surveys Let's just say I trust the authors that they did it in a sane way 🙈

The book touches on some very important topics for delivering software, It is highly focused around Continuous Delivery, and what is needed to get there. Fortunately many of the things described in the book are things that we are already practicing at Umbraco (my current workplace). 

Throughout the book, it covers practices that need to be in place to get Continous Delivery going those are

  • Version control for code
    • Everything should be in version control - code, configuration, and infrastructure. This ensures that we can replicate our current environments and that we always store the current state of the system.
  • Deployment automation
    • The entire deployment process should be fully automated, requiring zero or very little manual input from people in the organization.
  • Continuous integration
    • Integrate often, this is where rules such as no long-lived branches come in, they should be merged to the main quickly. changes that are not yet ready should be hidden behind feature flags, this ensures that we can get our changes into production as fast as possible to start the feedback loop.
  • Trunk based development
    • Or short-lived branches - simply ensures that code is integrated often, and WIP is kept at a minimum level
  • Test automation
    • Is a key factor in Continuous Delivery - we need to have enough tests to make us confident in that the system still works after changes are made. With tests in place we can deploy after all tests are passed, and the system builds
  • Test data management
  • Shift left on security
    • Include security early in the pipelines, so it does not become an afterthought. Fixing security issues late in the process can become expensive as it can require big architectural changes.
  • Loosley coupled archicture
    • Enables scaling
  • Empowering teams
    • A team should be empowered to make its own decisions, in regard to architecture and technology. It is inefficient if every change they make needs to go through an approval gate such as a manager or a Change Approval Board (CAB)
  • Monitoring
    • To ensure that what is being delivered works as intended, extensive monitoring is required to be in place. This will notify us, if a deployment contains errors or increases faults in the system. Thus we got some quick feedback. that can be solved fast
  • Proactive notifications
    • Listen to system trends (via monitoring), to catch cracks in the system, before they become real issues

 

All of the above should help you come to continuous delivery. The book also touches other things that will benefit from CD - like burnout of your developers, as time isn't wasted on dull release practices, but they can instead focus on delivering value in their software. 

All in all a great book that shows some conclusion from the state of DevOps report. Much of it surrounds the Continous Delivery practice.