More and more companies are adopting DevOps because it makes business more efficient. Transitioning to DevOps can come with growing pains, as can happen when implementing anything new, but those growing pains are made worse when mistakes are made. If you can avoid these top five mistakes when adopting DevOps, you’ll find that the process is much smoother and works as it was designed.
Boiling the Ocean
Boiling the ocean refers to making a big change in one fell swoop as opposed to making small changes in steps. Transitioning to DevOps changes your entire IT infrastructure. The way code is released and updated, the way security functions, the way systems and processes are tested, all of this changes. Nothing goes away, but operationally, things change. So trying to change everything all at the same time is going to result in problems with implementation, problems with communication, problems with people understanding what these changes mean.
For example, let’s say your internal systems and processes are extremely complex. You need to deploy all of them, you need to have a security audit and you need your systems to have additional functionality. If you do this all at once, in an untested environment, and think that the people who use these systems are going to adjust overnight, you are sorely mistaken. The human brain isn’t designed to work that way. Humans resist change, it’s uncomfortable. And if there’s no training on the new systems, because how can there be training if nothing has even been tested, then people are not going to take it well.
Not to mention that realistically, it isn’t going to work very well, especially if you don’t hire an expert to help you. Because you have bitten off way more than you can chew. You’re either not going to complete the transaction, which means you have something that is partially done and may just end up sitting off to the side. Or, even if the project is completed, you’re going to make a lot of mistakes. The majority of the time, the result is that the project isn’t complete and now you’ve wasted time, money and resources on something that isn’t doing anything for you.
Half Doing It
Often, you’re going to take the easy parts of the automation and you’re going to implement those. For instance, making it so that someone can push a branch and it will kick off a deploy process, or build a deploy process through something like circle CI or through BitBucket Pipelines. Then you deploy or the merge the build. But what it’s doing after you do that push is actually all still custom and clustered and not necessarily the same every time. It’s complicated and you’re basically just taking away an irrelevant step of pushing to trigger a rats nest.
So what you’re doing is still breaking all the time. The step you took away is having a coder go type a command somewhere. Which is fine, but doesn’t really do anything for you, it’s a step that didn’t need to be automated. Typing that command isn’t what is taking up time, it’s what happens after you type that command that never works. Which requires physical troubleshooting and manual intervention to fix. Which means that you haven’t actually transitioned to DevOps or made anything better. Instead, you have utilized time and money with essentially nothing to show for it.
Pretending To Do It
Pretending to do it is a little bit odd. This method to getting the project done is to basically start with a dashboard – usually the last thing you build. And it usually is spurred by a desire of management to know where features and delivery are in the process. For example, a Trello board or email tracking system is implemented to know where in the process things are – a dashboard. Or a tool may also be purchased that is supposed to be tracking the automation process. Except the automation doesn’t get built. Instead, all of the people who are manually doing the work now have the added task of updating the tool, which is counterproductive.
Management gets to watch the pretty tracker move across the screen and know what state the project is in, but the people actually doing the work have additional burden. They were already overloaded, and instead of helping by building the automation, now they have an extra step in the process they were already doing. So it looks pretty and looks productive, but the reality is the people doing the work are burning out even faster.
Improper Preparation
Preparation for something new is vital to pulling it off, no matter what it is. When it comes to changing the way your IT department functions, if you don’t prepare, be prepared to fail. As discussed above, humans are adverse to change. It’s uncomfortable, especially when functionality is not a problem. And benefits lie in making systems and processes function better and work faster which in turn allows the humans behind the controls to focus on other priorities.
In order for a transition to DevOps to succeed, you have to create a culture around the change. Let’s say you’re going from a traditional waterfall development house to a place where you’re doing continuous integration and continuous delivery. There are physical changes in the way code is written and people have expectations around how much code should be written and how different pieces need to depend on each other. There are expectations around how merges will work, how collaboration and testing will work. Because these things will change with adopting DevOps, which is why creating this cutlture is so important.
And when you don’t prepare people for that, you often get resistance from people especially those who’ve been doing something one way for 15 years. It can take time to get them to accept a novel way of working. Plus, if there’s no preparation, you could end up with half of your team doing things one way, and the other half working another way. Not everyone thinks the same way, so without direction, people will do things the way they think is best. When that happens they usually end up in each other’s way, causing friction in the work place because no one understands why someone else is working the way that they do.
What you end up with, in this scenario, is a team of people arguing over the correct way to do something. So what happens is the project gets abandoned because even though the current way of deploying code is clunky and takes a long time, it works. Everyone gets along. Projects are completed. But your business loses time and money because the process is inefficient.
No Maintenance
When you hire an expert to help you, they can’t just set it all up and walk away. They have to also teach everyone how to work with the automation because otherwise it’s just magic. Let’s say you want to start building components in a new language or with a new set of libraries because that’s what you should be using, which is great. But that expert is gone and if they didn’t teach anyone how to work with the automation, the magic has been happening that no one knows about will suddenly stop.
So you end up with a culture of people who rely on this underlying pattern of magic, but when they actually need to go in and change something because of modernization and innovation, it can’t get done because no one knows how anything works. So you just keep using the old thing even though it’s clunky and less secure, but replacing it or modifying it is now its own project.
The importance of hiring the right expert to help you implement DevOps is readily apparent when you consider the common mistakes. There is a proper way to set the foundation, to ensure everyone is on the same page and to make sure your expert is teaching your IT team how to run and maintain the new systems and processes. Adopting DevOps, like anything else new in IT, comes with bumps in the road. Don’t make cracks in the pavement by making avoidable mistakes.