The Principle of Flow
The process used to write code and deploy it to production is the biggest contributor to your team’s velocity.
You’ve probably been in the situation where something is seriously broken in production and you need deploy a fix right away. You may have even tried to circumvent the existing process to deploy it faster. So simply put, the faster team can write and deploy code to production, the better. This is the principle of flow or the “first way” of DevOps.
The DevOps Handbook provides a two-step process for achieving fast flow from development to production.
+ Step 1: Use trunk-based development and continuous integration.
+ Step 2: Use continuous delivery.
Now, you’ve probably heard these terms before. They’re thrown around and often used incorrectly.
Continuous integration is a prime example. So, I’ll do my best to clarify the right and proper way to achieve fast flow from development to production.
The goal at the end of each development cycle is to produce production-ready builds, built from master that have been verified in a production-like environment and validated with automated tests. That’s continuous delivery in a nutshell. Continuous deployment takes it one step further by automatically pushing code to production... But that’s a topic for another episode.
For now let’s start with trunk-based development.
I bet the mere mention of “trunk” makes some of you shudder. Some of you may even be thinking: “trunk what is madman talking about SVN for? We use git so what’s the point?” Well, the point is to reduce cycle times from development to production. Trunk-based development optimizes for team productivity instead of individual productivity, which is a great way to achieve that goal.
The trunk-based development boils down to keeping branches small and maintaining an incremental straight line of development. Branches should be merged to trunk (or master) at the end of each day.
It must also be covered by automated tests so it’s clear which commits are broken. This is the origin of continuous integration (and, believe me, they’re a lot of “continuous” things in DevOps). This practice ensure commits are smaller, thus easier to write, test, and deploy to production hence improving times from development to production.
I can hear some of you saying: “Adam... Wait, what are you talking about? Why does this make any sense? What am I supposed to do with my feature branches? What about those epic branches that are open for weeks?” Well, my answers to that question lies in a perspective shift regarding individual roles are and what a team values, but I want to put these questions in another way.
Ask yourself this question: would you rather work in your topic branch for as long as possible or would rather get your code out the door and into production? I choose production and I think you should too.
But, I don’t want to get too far into the weeds on this area because it’s somewhat controversial so check the show notes for more links in discussion on this topic.
For now, let’s move forward to continuous delivery:
The idea here behind continuous delivery is to connect commits from trunk or master to an automated deployment pipeline that verifies builds are fit for production. Naturally, this requires varying levels of tests and automation.
Now, don’t get lost in the statements from the blogosphere that you need Docker or microservices and all this stuff to achieve these goals. These proclamations miss the point that technical practices like infrastructure as code and automated testing are more important than specific technologies. Let me repeat that: practices are more important than specific technologies.
So, there’s no prescriptive solution but I’ll provide you an outline:
+ Step 1: Deploy code to a staging environment.
+ Step 2: Run a test against staging.
+ Step 3: Deploy code to production, ideally using a blue/green strategy or canary.
+ Step 4: Run smoke tests against production.
+ Step 5: Is it all good? Well great, you’re done. If not, then rollback.
Then expand out to more pre-production environments as necessary. You may have a dedicated performance testing environment, or a manual QA environment, or whatever floats your boat. Really, honestly, it doesn’t matter how many environments you have as long as the promotion and verification is automated as much as possible. However, your number of environments will grow over time as your deployment pipeline becomes more rigorous.
Alright, that’s enough for this batch. The principle of flow covers reducing cycle times from development to production. Trunk-based development backed by continuous integration and continuous delivery is the best way to achieve that.
The book Accelerate provides two metrics to measure flow: lead time and deployment frequency. Lead time is how long it takes to go from commit to production. Deployment frequency is simply how often deploys happen. Accelerate also breaks down these metrics into tiers.
Top-tier lead times are under an hour. This means a developer can start working on and deliver completed code to production in under an hour. Mid their lead times range between one week and a month. So, where does your team stack up?
Anyway, that’s a wrap on this episode. Head over to the podcasts’ website smallbatches.dev for a transcript, show notes, and links to my review and further analysis on both the DevOps Handbook and Accelerate.
Until the next one, good luck out there and happing shipping.
Creators and Guests
