Strategies: Building DevOps in your Organization
Note: This is part of a series on Enterprise IT Maturity. See my earlier post on Building QA in your organization.
There comes a time in the life of a company where the loosely-structured infrastructure & release management practices of the "early days" require leveling-up into more structured practices suited mid- to later-stage growth. That's where the need for DevOps arises. If you're wondering whether the time is right for your organization, here are a few thoughts on the adoption process:
When do you need it?
DevOps should follow more of a pull than a push model. (i.e. the pain of not having it should be real to all parties, be they at the technical or executive level)
Deployments are unpredictable. (“Oops, I fat-fingered a step, so the deployment failed”)
Releases are time consuming (if your release takes longer than 5 mins, you’re likely a candidate)
Infrastructure behavior is unpredictable & can’t be easily monitored, scaled, or reset
Key things to do
Define your build & deployment processes as a generalized pipeline. By that, I mean that it should accommodate all applications, regardless of tech stack, and characterize all events that take place over the end-end release lifecycle. This model should govern how code changes are merged, builds are triggered & versioned, which environments exist, and how deployments are made to those environments, inclusive of post-deployment events such as QA, performance, or security analysis.
Summary: your enterprise may have 15 production applications, of varying tech stacks, but a well crafted pipeline model should accommodate all of them.
Define your infrastructure as code. Non-standardization and drift on your build and host infrastructure can become real problems, so define that infrastructure as code, using scripting tools that allow you to easily tear down, rebuild, and audit your machines.
How to proceed
Don't throw the baby out with the bathwater. If your team has multiple apps, start working with just one, and create the new deployment pipeline in parallel, so you can always fall back on the old deployment process.
Make it a team sport. Your key constituents include Developers, DBA's, QA and the CTO. After each successive run of your new DevOps processes, identify someone whose department has benefitted. The promise for more process improvement may trigger ideas on further refinement. Remember that this should be a pull-based exercise - i.e. they should see the value & want more!
Be ready to get in front of your colleagues to explain certain changes to their workflows. Put on your communication (or technical writing) hat!
How do you know when you've succeeded?
It goes without saying that there's no finish line here, but if you can trigger an entire release with a single button or script, and the process is generalized enough that it can be repeated without having to manually setup or tear down anything, then you've got something good.
The Takeaway
So there you have it. If you feel like starting down this road, it’s a good idea to seek expert counsel, rather than stumble blindly through the fog. Hopefully, this post will help identify when you’re ready to post that first opening for a DevOps Engineer. Whatever the case, I hope these thoughts help position your company to grow fast, while avoiding the growing pains.
