Everyone loves to talk about DevOps, but when it comes to real life enterprise implementation, things start to get a little shaky. Having gone through the process with hundreds of organizations, the XebiaLabs Sale Engineering Team relayed to me the 6 most common mistakes they see when enterprises implement DevOps for the first time. Change is never easy, but if you can dodge these top 6 mistakes, your transition to DevOps can be relatively painless.
Not Getting Buy-in Early in the Implementation
Go to the person that “owns the box” on the Production (aka “Ops”) side. Talk about your initiative, and help him/her understand how this will benefit the Operational teams. (goal: one-button deployments in PROD) Be willing to partner closely with this person, providing updates (demos, training) for the Operations teams.
Not Having a Transition Plan
Once you have some of your releases automated in this new “DevOps” way, Operations is forced to have two different deployment processes: the new modern “automated” way, and the 17-page deployment spreadsheet. As you start to have success in Production, it’s important to talk and plan how to bridge your DEV teams delivery models.
Automate 2-3 Apps From DEV to PROD
This will help you discover all of the… “nuances” of your application delivery process. Which people are involved, what requirements do you have, etc. You may already know this, but automation forces companies to think about how these things will change for the better.
Only Automating in the Lower Environments
Most Development organizations can implement automation in their DEV and Integration environments. But getting to environments like QA, Stage, Pre-PROD and PROD require a lot more thought about the implications of automation. If a DevOps team is not empowered to make changes along the entire delivery path, then you will find your DevOps initiative fizzle out in this “half-auto” mode.
Creation of a DevOps Team Outside the Existing Ops and Dev Teams
One trap people fall into is introducing yet another silo. The intention is good, a “painless” migration for certain projects, but in practice it becomes too easy to circumvent this team or worse use some fast route through this team to avoid good practice that exists in the other teams. I have seen teams avoid this trap by embedding “Ops” into the development scrums. This is often resisted (“too busy cutting trees to sharpen my axe”), but those that manage it learn a lot and start to see the progression to a working DevOps organization.
Focusing on the Wrong Thing
The main difference between doing DevOps right and otherwise is how the people interact with each other. Shared knowledge, common goals, desire to succeed are all traits of organizations wanting to do it right. This is harder the more people and business structure there is involved, lots of things have to change in a large organization to make this work, and some of those changes will disrupt other areas of the business, possibly for the worse!