Accelerate - Continuous Delivery

If you are a developer, or in any level of development management, you should read this book.

Accelerate is a book by Nicole Forsgren PhD, Jez Humble, and Gene Kim

I love this book so much. I have read a lot of good books with business advice based on the experience of successful people. This book is based on solid data and research collected over 4 years, not just someone's experience and opinion. Even with the stats and research on prominent display, the book is easy to read. The analysis and conclusions are clearly presented and organized.

The tagline of the books is Building and Scaling High Performance Technology Organizations. As a senior developer at a young startup, this is all very timely. If you want to skip to the end, they list the "24 key capabilities that drive improvements in software delivery performance in a statistically significant way" in appendix A. However, that will not give you the context and the why behind it all. So you should still read the whole book. After I finished the book, I left a bookmark at that appendix for quick reference.

Key Capabilities

The 24 capabilities are organized into five categories.

  • Continuous delivery
  • Architecture
  • Product and process
  • Lean management and monitoring
  • Cultural

Over a few posts I am going to run through each and provide my summary/thoughts. I am going to start with Continuous Delivery, which is 8 of the 24 capabilities.

Continuous delivery

Use version control for all production artifacts

This one is the obvious low hanging fruit. I have not worked on a software team that does not use version control, and I would not work on a team that doesn't.


Automate your deployment process

Also obvious, but much more difficult to accomplish. I spent a lot of time automating deployments while I worked at VoiceFoundry. That was all AWS, so it was a lot of CloudFormation, Serverless Framework, CodePipeline, and some node scripts using the AWS-SDK. I did some work in Jenkins and a very small amount of Terraform. I enjoyed that work quite a bit. It was tricky but so worth it.

Few things are more satisfying than a smooth automated deployment process. It makes deployments quick and easy, and more importantly, it reduces opportunities for human error. This becomes more important when you get to the next couple capabilities because you are ideally deploying regularly. If deployments are painful, your developers will not be excited about making regular deployments.


Implement continuous integration

Continuous integration is the first half of CI/CD, but it has enough value on its own if done properly. And by properly I don't just mean that you merge code regularly. A CI process should include automated tests on check-in, and automated builds. Checking in regularly is also very important. The bigger the PRs get, the more likely you will run into merge conflicts, and the more difficult it will be to debug when you find an issue with your branch.


Use trunk-based development methods

Trunk-based development is a whole thing, and every team I have worked on follows the basics of this model. A couple key points that not everyone follows is keeping branch and fork lifetimes to less than a day, and never or rarely having "code freeze" periods. Every developer who has reviewed a PR has probably reviewed (and created) a PR that was bigger than it should have been. It is certainly possible to make your PRs too small, but I have very rarely seen that cause problems. Large PRs on the other hand can be awful.


Implement test automation

While this should be part of continuous integration, it rightfully has it's own bullet point in the book. I'll be honest, I don't like writing tests. That is probably not an uncommon sentiment, but they are very important.


Support test data management

Not as deep of a topic as the others, and the benefits are obvious. However, this is easy to overlook. As a frontend dev, I often have to generate a lot of test data, and different sets of data to test pagination and such. It is a much better use of time to have developers writing code instead of creating and manipulating test data. For my current local development setup, I created a Postman collection that will seed a cleaned database to give me enough data to test the UI, and test all of the API endpoints at the same time.


Shift left on security

There is not a lot of content in the book on this, but they lay it out pretty concisely on page 56, Chapter 4.

"High performing teams were more likely to incorporate information security into the delivery process. Their infosec personnel provided feedback at every step of the software delivery lifecycle, from design through demos to helping with test automation"

Implement continuous delivery

So this is kind of what the previous capabilities have been leading up to. The others are all sufficiently important on their own, but without them, you are going to have a hard time with CD. The goal is to keep your software "in a deployable state throughout its lifecycle". To do that, you can't merge changes that break the build or otherwise put it in a non-deployable state. You can't merge changes that you haven't thoroughly tested. And if something does slip through (something always does) you drop everything and fix it. Deployablility at any moment is the priority.


You can read more about continuous delivery at continuousdelivery.com. I will cover the remaining capabilities in another post. If you have any thoughts, questions, or corrections to what was discussed here, drop it in the comments.

Comments

You must log in to leave a comment