I gave a talk today at DevOpsDays Raleigh entitled It’s Not Continuous Delivery If You Can’t Deploy Right Now (slides here). I had some great questions later in the day so wanted to add a bit more followup…

I’m not a fan of using how often a team deploys as a metric.

John Willis pointed out that lead time for changes is a great metric, and the ability to deploy quickly can have an effect on that. I couldn’t agree more.

I also was given an example later in the day about a particular instance where a consecutive set of changes needed to be applied in a certain order. The faster those changes could be deployed, the smaller (and hence less risky) that deployment would be. Again, awesome example of a need to deploy quickly.

When I say I’m not a fan of the “how often I deploy” metric, I mean as a stand alone measure. If it enables a business goal, awesome! By itself, not so much.

Trunk (master/mainline/other) based development.

There was a question about how to do code reviews when you’re doing trunk based development. I commonly see a few ways:

Pairing. I’m a big fan of this anyway, but a lot of teams will use this as the code review. This is especially true when it’s actual “move the keyboard from person to person” pairing.

Pull Requests. When I’m working on something under Git’s control, the first thing I do is type ‘checkout -b branchname’, creating a new branch. Each day (at least) that code can be submitted as a pull request for review. A good example of this is practice is the DevOpsDays.org website. You can see the contribution guide here.

The biggest thing I want to avoid when advising people to avoid feature branches are long lived branches. It’s not at all uncommon for me to see branches which last for days, weeks and even longer before any work goes back into trunk. This is a recipe for disaster.

I’m not saying don’t create branches, I’m saying push code back in at least daily. My go to resource for details about this is Martin Fowler’s excellent article on the topic, found here.

Another really good resource for more on trunk based development is, you guessed it, trunkbaseddevelopment.com.

Pipelines of a different length

I show a version of the following fairly often…

The idea here is that we may have longer running tests which we want to make sure have passed before we’re willing to deploy to production. They are performance related in this image, but could be compliance or really anything else.

The question came up; “Doesn’t this mean I could deploy to staging several times while those tests are running?” Yes, you could.

In this diagram the purpose of staging is to test the deployment of our software on a production like environment. So, if production is going to be a cluster, staging needs to be a cluster, although potentially not as big. Like all of our tests, we want to know as quickly as possible if we have a failure, even if that build isn’t going to end up going out to the world.

Shameless plug, this use case is one reason my company ThoughtWorks created GoCD. It will enforce the fact that the build which gets deployed to production has passed all of the pipelines in it’s value stream, even if they don’t run at the same speed.

Thanks for the feedback and questions!

I can’t say how valuable it is to have these types of questions asked after a presentation. It allows me to make it better the next time!