DevOps 101: How to kick-start your DevOps initiative
This is the third part of my DevOps 101 series, so before we get going, let’s do a quick recap of what we’ve covered previously
In DevOps 101: What, who, why, and how, I talked about how the definition from Microsoft’s Donovan Brown encapsulates DevOps succinctly as: The union of people, process, and products, to enable the continuous delivery of value to the end users.
This definition is key when we talk about getting started with DevOps, as a lot of people get hung up on a particular technology or process, when it’s people that need to come first. Speaking of people, when we think about who is involved with DevOps, the short answer is everyone.
So how do you get started with DevOps? In DevOps 101: How do you get buy-in from people?, I explained how you should measure your pains, identify your champions, adopt the language, educate people, and measure your gains.
The reality is it’s nothing complicated, you just kind of go, but there are certainly things that are going to cause you pain. And it’s these things we’re going to cover today, starting small, measuring against those pains I mentioned above, documenting goals, publishing your results, and adopting DevOps principles.
Starting small
The big fear here is trying to boil the ocean or trying to do everything all at once. By starting small and focusing what we do, we can get more done, successfully. So to kick-start your DevOps initiative, you need to pick just one thing.
Ultimately you want your entire business using DevOps processes 100%, but if you try to bring ten different teams into the project all at once, frankly you will fail. When implementing DevOps for the very first day, first week, first month you’re not going to work quite as fast as you normally would.
So rather than disrupting all your development and operational teams at the same time, focus on one team and one project instead. This will allow you to fix the DevOps stuff as you go, and not spend your resources wrestling with multiple teams, multiple projects, and multiple communication mechanisms. Ultimately, it will make it easier for you to be successful.
A common analogy I hear is, how do you eat an elephant? The answer? One bite at a time.
You know it’s this giant thing with lots of pieces, but you don’t have to start with all of them. What you’re going to do is start with one piece of the process you want to improve. I generally like to start at the end point: define this and then work backwards from there, documenting the process as you go.
You have to work through a series of steps one at a time, then slowly and carefully add new steps to get to a point where you’ve got faith in what you’re doing. The best way to build faith in the system is to automate it. You’ll then be able to test it and repeat it over and over again, and because of this you develop faith in how that system works.
So, pick one team, one project, add steps carefully, and build in automation so that you can add more. That’s the fundamentals of starting small.
Measuring against your pain
Make sure you emphasize the gains against the pain. Let people know both what it used to be like, and what it’s like now, because people forget pain. They forget that what now takes 15 minutes for deployment used to take four hours, so show them through a documented process the results that you’re achieving.
Update them frequently, and if you can build a continuous update process so people know how many tests are being run, how many of them are successful, and how often deployments are successful, especially compared to what you used to get.
You’ve got to have these measurements in place initially, so you can see the progress moving forward. But what are those measurements? These will be specific to every organization, team, and project. Maybe it’s that you want to deploy changes daily, so you know you’re delivering new functionality for users daily. So, the goal is daily deployments: measure whether or not you’re hitting that.
I don’t want to say that there are specific measurements you have to follow as you have your own pain and your own goals. You’ve probably defined these already and you’ll know what they are. If you haven’t, just think about the pains everyone complains about. Now ensure you measure against them and that you’re achieving the stuff that you tried to.
Documenting goals
Communication is key to DevOps; you need a method to communicate across teams and disciplines. That’s your documentation, writing down what you’re doing and why you’re doing it. Set SMART goals which enable you to validate everything you’ve done and ensure you’re achieving what you set out to.
As outlined before, you can determine and document your goals, and you need to measure your pain. Make sure you know that your deployments are painful, that you are taking days to do a deployment that probably should take hours or maybe even minutes, that you are causing outages during your deployments when you have take everything offline. Measure that pain, refer back to it when talking about goals and document them so that you can communicate to everyone what it is you’re doing and why.
Publish your results
You absolutely need to share your results with the whole organization, not simply within the team. Let everyone know what you’re doing and include both the good and the bad. ‘We automated deployments, but we didn’t get it quite right, so it’s actually slowed down some QA testing, until we get this deployment fixed.’ You’re going to write that down to let people know that you haven’t yet hit your goal, but you’re on the right path.
Don’t simply publish your results, promote them. Let everyone in the organization know what you’ve achieved, and how. Don’t wait for the annual meeting – send emails, write blog posts, create Slack announcements, anything to make people aware of what you have achieved. You’re automating, you’re supporting people better, you’ve got a more defined process, you’ve got tooling that makes it all work.
Tell everyone, because, when you start to expand to more than one team and one project, you won’t have to go and find them. Instead, they’ll be knocking down your door saying please, please, please, let me get the same results you’re seeing. That’s why you publish and promote it.
Adopt DevOps principles
You want to start adopting DevOps principles for everything else you’re doing. You’re working on a DevOps process, putting people first, figuring out the process, documenting that, and then automating it through tooling. Iterate that the same way as you would iterate your code.
Make sure you’re constantly trying to improve the process you’ve already defined, because you may learn over time that your initial goal was not high enough, you could go faster, and you need to make a couple of additional process changes to get there. Or you may make some poor choices initially in your process, don’t get hung on what you had written down, you can always make changes.
You’re going to adapt as much as possible in response to feedbacks and measurements, and that’s why you need to ensure you’ve got the feedback and measurement processes in place. This will then allow you to apply DevOps principles to the actual processes you’re building.
DevOps 101 summary
One thing which is key to success is remembering why you’re doing this It’s not because DevOps is cool. You’re here because your deployments have been slow, problematic, and even destructive. You want to arrive at a place where you can deliver more functionality faster for your end users. Don’t get too caught up in the details. You need to make your deployments better, so what do you need to do to achieve that? You have your goals and a map you’re following to achieve those goals, that is your focus.
The key to this is understanding your people. Do they have the tools they need, do they understand the process, are they documenting the process – can they do the things they need to do? As Donovan Brown outlined, it’s people first, process second, tooling third. So, make sure you’re training, educating, and supporting your people. They need to effectively communicate with one another to build a process that’s going to better support them, and then identify the tools they need to support that process.
Continual improvement of the process is your goal. From there you can then expand into other teams and other projects. You don’t want to boil the ocean and try to do everything at once. Instead, you’re going to adopt these methodologies; start small, document goals, use your pain as a starting point, publish and promote the results.
Measure everything so you know you’re achieving what you set out to, and then adopt those DevOps principles which will allow you to iterate processes, before expanding it out to the rest of your teams, projects, and organization. That’s how you kick-start DevOps.
If you haven’t read them yet, you can catch up on the other posts in this DevOps 101 series:
You may also like
Blog
What is Test Data Management (TDM)?
Blog
Four steps towards tackling the complexity of managing multiple database platforms
Blog