DevOps is currently the train every enterprise wants to climb aboard. In fact, many of today’s market leaders already have some sort of DevOps plan in place. As companies incorporate IT further into their business, DevOps is becoming a basic necessity for the modern enterprise.
However, when it comes to actually implementing DevOps in real life, things can get a little shaky. Having helped many organizations go through this process, I’ve pinpointed some common mistakes and misconceptions — and some best practices — from enterprises when trying to implement DevOps for the first time. With the help of this DO and DON’T guide, your transition to DevOps will hopefully be much smoother.
DO get executive buy-in early in the implementation
Successful DevOps involves more than just the IT department. Business leaders also need to be clued into the transition process so they understand that a successful DevOps implementation is a key step on the way to delivering great software, a strategic priority that’s critical to business performance. Make sure you have a clear goal to communicate, talk about your initiative, and help key leaders understand how this will benefit the entire organization.
DO get everyone involved in the DevOps transformation
The main difference between a smooth and not so smooth DevOps implementation is getting everyone on board and working towards a unified vision. Shared knowledge, common goals, and the desire to succeed are all traits of organizations committed to doing DevOps right. Companies that focus on the various facets of DevOps — people, process, and tools — rather than trying to implement each in isolation will see greater overall success.
Remember, DevOps is a journey, not a switch that you turn on or off. When planning a DevOps migration, identify the different stages you’ll pass through so there are no unpleasant surprises. Also, start small. For example, implement some basic DevOps tools across a handful of teams and keep working from there until you reach full,continuous delivery.
DON’T create brand new teams
One trap people fall into is introducing yet another silo via the creation of a DevOps team, alongside the existing Ops and Dev organizations. While the intention is good, it becomes too easy to circumvent this new team. Or worse, some people will exploit a fast route through the DevOps team to avoid good practices that exist in the other teams. We have seen teams avoid this trap by embedding “Ops” into the development scrums. This system is often resisted (“too busy cutting trees to sharpen my axe”), but those who manage it learn a lot and see faster progress towards a working DevOps organization.
DON’T disregard complex enterprise environments
It is a common misconception that DevOps doesn’t work in complex enterprise environments, when in fact DevOps is actually made to thrive in them. Large enterprises typically suffer from lack of communication between teams about the state of, and changes to, interconnected projects and systems. DevOps, on the other hand encourages communication and collaboration, which helps prevent these issues from arising. The risk that needs to be avoided here is that unrealistic and/or inappropriate goals are set.
DO empower teams to make changes across the entire delivery path
When it comes to automating certain environments, it’s to the organization’s benefit to empower the IT team to make changes along the entire delivery path. Most teams can implement automation in their Dev and Integration environments, but getting to QA, Stage, Pre-Prod and Prod requires a lot more thought about the implications of automation. Consider starting with one software project and map out all the steps in the release process, from design through production. This helps uncover all the “nuances” of the application delivery process — the people involved, the technology requirements, and so on. Automation forces companies to think about how to improve the entire value chain, but if teams feel restricted to parts of the process, your DevOps initiative will fizzle out in “half-auto” mode.
DON’T do what everyone else is doing
There’s no one-size-fits-all DevOps toolset, process or practice. In other words, the DevOps approach that one company uses may differ widely from that used by another organization. An enterprise that’s planning a DevOps migration should expect to customize its toolset heavily, and may even need to commission some new tools to meet its unique DevOps needs. Grabbing stock tools will not be enough for a successful enterprise DevOps operation.
That’s not to say you’ll need to rebuild everything from the ground up to do DevOps. Rather than reinventing the wheel, look for ways to make the tools you already have in place — like PaaS platforms or flexible infrastructure technologies such as Docker — help you in your DevOps journey.
DO be proactive about security
Ever wonder why most conversations about the benefits of DevOps are tainted by a skeptic’s concern of its associated (supposed lack of) security? It’s easy to disregard the security aspect of DevOps until things go into production. Remember, being reactive to an application hack will cost your organization more money than if you’re proactive about preventing it. The trick is to integrate security into the process of DevOps as a major priority.
Enterprise DevOps certainly has its challenges, but even the largest of organizations can successfully implement DevOps if they treat it as a journey rather than something they’ll accomplish overnight. It’s also important to recognize that DevOps is about more than just spinning up a few open source tools and expecting magic. You need to make sure the processes and tools you use are the best fit for your organization and that you can scale your DevOps implementation across the enterprise. All of this takes some work. But the benefits enterprises will gain by making the switch — especially, faster time to market — will provide a crucial competitive advantage.
Andrew Phillips is VP of DevOps Strategy for XebiaLabs