When you create a DevOps workflow, avoid these missteps

The operations team wants control, security and reliability. Developers need to create, enhance and experiment.

So how does an organization integrate these sometimes-unaligned forces into a DevOps workflow that adds security and reliability to the dev process and at the same time empowers developers to deploy and test without miles of red tape? There are ways to do this that will deliver DevOps success. And there are plenty of paths that will lead to DevOps regret.

Reorganizing development and operations teams and their duties is complicated, but your chances of achieving better outcomes will increase when you can avoid common DevOps mistakes.

Too little automation

Automation underpins much of what companies attempt to do in IT. It’s why the term has become one of the biggest industry buzzwords. Sometimes the benefits of automation are seen near the end of a project, but that doesn’t mean they aren’t crucial for DevOps success.

It needs to be easy for developers to push their code changes quickly and then have those changes compiled, distributed and tested. Without some or most of these tasks being automated, operations will be inundated with a million tiny changes to approve. This will interrupt a smooth DevOps workflow by getting in the way of quick iteration, one of the central tenets of DevOps.

Missing the metrics

With frequent code changes, you need to test regularly and reliably. This capability gives your team the feedback necessary to attack problems right away. How else are you going to report back to management that everything you just created in your new DevOps workflow performs as expected and isn’t going to break in production?

With the right metrics, you won’t be in the dark. You can measure and monitor everything. Without that information, you won’t know what may have gone wrong, or which test is falling.

Understanding how each area operates is essential to the creation of a productive DevOps workflow.

Metrics and automation give an organization a chance to create a DevOps pipeline in which rapid development can take place. The idea that your developers can quickly make a change and then proceed to deploy, test and validate that change without having to necessarily involve operations empowers every team. This works because operations has the monitoring and automation in place to take positive control when things go wrong, but developers have the testing framework and safeguards in place to minimize trouble.

Leadership that doesn’t lead

One of the key ingredients of DevOps success is to operate with T-shaped teams. These are teams where members have both a broad understanding of the entire DevOps workflow and expertise in specific areas. This way, all members can easily communicate with each other to solve problems efficiently.

With traditional teams, individuals tend to specialize in just one or two areas. This can make rapid collaboration difficult. When everyone has a closer-to-equal stake in results, you promote the end-to-end responsibility needed to make a product successful.

These types of teams, though, don’t just happen. Leaders need to create them. An organization needs leadership to fully buy into and support the DevOps mission, and, in some cases, to force different units to work together effectively.

In small teams, this could be a problem, as you may not have the training and capacity for your personnel to meet these needs. This often means a business will need to hire workers with that broad skill set or commit to better training for current staff. Understanding how each area operates is essential to the creation of a productive DevOps workflow.

Survive a DevOps transitionTECHTARGET

DevOps is a cultural shift as much as a technological one. The extent to which leadership buys in and supports those teams will make a big difference in how well this new approach works in a particular IT organization.

Deciding but not doing

Sometimes a company decides the best way to adopt DevOps is simply to declare it will adopt DevOps. By itself, this doesn’t accomplish much. Management might even applaud the successful transition to DevOps — even though nothing much has changed. A company might hire someone to be its DevOps engineer, but that person will inevitably be spread too thin and become a single point of failure for end-to-end knowledge of what was happening with the DevOps pipeline.

Management in this type of organization doesn’t realize that DevOps isn’t a hiring strategy or a piece of software. It’s a collaboration and coordination between teams. It’s a cultural shift first, and the rest must follow from there.

Overemphasis on technology

In a startup culture, everything tends to revolve around technology and the bleeding edge of the bleeding edge. In that environment, it doesn’t take long for a small team to figure out how to work together across the development-operational divide. This certainly puts in place the right culture for DevOps success. At the same time, it can take focus away from the reasons the organization chose to adopt DevOps in the first place.

It’s good when a team is able to automate unit testing, integration testing, acceptance testing, deployment, delivery and everything else it can. But all that effort can distract from actual development tasks in the DevOps workflow. When software isn’t being developed, and releases fall further and further behind schedule, a technical team has lost sight of the business purpose of what’s supposed to be created. That team has forgotten that its job is to develop software and help build a business — and not just create a really cool DevOps pipeline.

DevOps requires time and effort, and adoption will present plenty of challenges. With proper planning, though, you can adopt a set of principles that might transform an organization. A successful DevOps workflow can deliver agility, focus and quality in ways that traditional methods can’t match.

DevOps isn’t easy to adopt, and there are plenty of reasons it will disappoint people. The horror stories result from a lack of preparation or when implementations are rushed or if focus is lost.

With a good plan, effective automation, useful metrics and committed leadership, it is possible to create an environment that’s conducive to continuous improvement. A downside is that with all of this complexity, things can and will break. The tradeoff is the increased productivity and ability to respond to requests and changes rapidly.