Playbook for DevOps
“Change is the only constant.”
– Heraclitus, a Greek philosopher
Many times, the toughest part of DevOps is simply getting started.
Before you even start running plays, it’s important to perform a value stream mapping of your current process. Value stream mapping is a method to illustrate, analyze and improve the steps required to deliver your application. It allows you to take a look at the inefficiencies that exist in your process today. (For more in-depth reading on value stream mapping, check out A DevOps Adoption Playbook by Sanjeev Sharma.)
Start with the developers and work your way through the entire process.
- “How do you start a project?”
- “What do you do with your code once you write it?”
- “What if there’s a database change that needs to happen?”
- “Do you ever have to wait for something to happen so you can keep working?”
- “What do you think is the biggest blocker to getting your code into production?”
Wherever the questions take you, follow them to the next person in the process and repeat. This eye-opening process will uncover all sorts of information. You’ll learn where the wait-states and unnecessary process steps are happening. You’ll notice a lot of inefficiencies happen around handoffs between stakeholders.
Once you’ve mapped out and examined the process, you’re ready to develop some plays based on what you’ve learned.
Play 1: Remove the biggest bottleneck
No two value stream maps will end up looking alike. Not everyone has the same issues. Maybe you found that handoffs between your developer and your DBA take days. Maybe you find that your developers have to wait a week to get a proper environment set up. Whatever you found to be the biggest bottleneck in your value stream mapping exercise, fix that issue first.
Play 2: Keep going
Take on the next biggest bottleneck.
Play 3: Don’t stop
That’s it. In order to drive DevOps success within your organization, you can’t stop.
You’re never done with DevOps
Many executives fall into the trap of thinking “We’re done! We’ve completed the DevOps initiative!” They achieve level 5 on their maturity model and they stop investing in getting better.
DevOps is a lot like getting in shape. You can’t just buy a gym membership and expect results. You need to put the work in. If you want to run a marathon, you need to train. If you want performance outcomes it requires good shoes (automation and technology), changes in habit (optimizing processes), and friends/accountability (culture investments).
When you train for a marathon, you also need to gather data to make sure you achieve your goals.
Four key metrics to track
There are four key metrics software teams need to continuously track because they directly impact Availability, which impacts the promises made to your customers:
- Lead Time
How long does it take to get from code check-in to code in production?
How often do we deploy code?
- Change Fail Rate (% of changes that fail)
Does the code cause an incident or require human attention?
- Time to Restore
How long does it take to get back up if there is a problem?
DevOps has crossed the chasm
According to many analysts, DevOps has crossed the chasm. This means more and more companies are realizing results using DevOps.
This is an exciting time because anyone can master DevOps. It’s also a scary time because your competitors are getting better at DevOps. They’re purchasing technology that enables their teams to deploy faster and they’re optimizing their processes to ensure they win the next race.
Your goal in running any DevOps play is to develop and deliver software with speed and stability so that you can deliver value to end-users and customers.
That never stops.
Summing it up
There is no silver bullet tool that can magically solve all of your DevOps problems. Don’t believe any vendor that tells you they can solve DevOps in general. Look for vendors that can help you solve the specific issue that’s in the way of your team delivering software with speed and stability. For example, Datical can help your team remove the bottleneck between development and DBAs and ensure database code gets deployed without errors, automatically.
Technology changes, teams change, and competitors change so you need to keep evaluating your software release process and keep optimizing.
Interested in learning more about how to remove the bottleneck from your database schema change and release process? Sign up for our Demo.