To get DevOps right businesses need to be clear about the end goal

Source: techerati.com

DevOps does not equal automation. To make DevOps succeed, organisations need to focus on automating their constraints, minimising bottleneck and focusing on measured improvement, writes Jeff Keyes

“DevOps is not about what you do, but what your outcomes are,” said the wise Gene Kim, and we would do well to heed his direction. What he’s urging us to remember is that while DevOps is about enabling a faster speed of working throughout the development process, fundamentally it needs to help in achieving results. Unfortunately, this often gets forgotten in modern-day DevOps practices.

Here are five common mistakes that can occur in DevOps if the end result is not constantly top of mind and how you can avoid falling into these dangerous traps.

If you’re doing it right, you need to measure it right

It is a common belief that, at its core, DevOps is simply about automating everything, but this can be a simplistic view. Once you automate, are you actually delivering a better outcome?

The answer is not always simple. While metrics such as deployment frequency or mean time to repair (MTTR) are important indicators, they don’t necessarily determine if your team is delivering actual value any more than measuring the number of lines of code submitted or counting the number of keystrokes by the development team. Before measuring outcomes, you need to establish a baseline to understand where you start and where you end.

A key part of this is understanding that DevOps is so much more than automation. It’s actually about the entire pipeline and how your team moves through it from ideation to delivery to production. Even large companies that are leading the way in DevOps aren’t always the best role models for defining the problem, managing the value stream, and putting together multiple pipelines.

For example, I have had conversations with organisations that claim to have been “doing” DevOps for 18 months yet hadn’t delivered anything into production in that timeframe. But is this really implementing DevOps? DevOps is a process, sure, but if it produces zero value it’s not delivering on its promise.

To combat getting into this situation, the focus should be on delivering value and measuring that value as it is delivered into production. However, as mentioned before, you can’t measure value added if you haven’t defined what it means to your organisation as a whole and each individual deliverable.

Common metrics to track include the number of story points, actual revenue from product comparison and customer satisfaction. By starting with clearly defined metrics, you can measure value as it gets delivered to the customer.

Environment stability is key

One weak spot in the DevOps process is pre-production environments, where code gets deployed and tested. Automating a delivery pipeline is reliant on code being built and deployed into a variety of environments.

If environments are not robust, developers and testers find themselves wasting time fixing problems in the environment instead of testing and fixing the code itself.

“When the environment is unstable, you are gambling with the whole pipeline”

In an ideal world, environments would stand up on-demand, but the fact is most do not. Another DevOps legend, Randy Bias, has an analogy about pets versus cattle in describing servers, and the same analogy can be used for environments. If environments are not standardised and repeatable, you have to be willing to move on from it like a farmer moves on from livestock; you can’t hold onto sentimental attachments like we have with our pets. What needs to be prioritised is ensuring that no environment is singular in nature.

A key piece of the solution is to create code and automate, but to make this work it is important to build environments that are complete. Every environment needs proper builds, proper data and proper tests validating the environment. Additionally, the automation must be stable and able to perform successfully every time. If you have a piece of automation that fails even just 5 percent of the time, it throws everything off.

The only way automation works in an environment is if you can trust the environment. When the environment is unstable, you are gambling with the whole pipeline. This kind of problem can be hard to identify; it could be in the environment, or it could be in the code, the data, the middleware, or a number of places. When a problem arises, engaging with the developers should be a last resort, but they often get pulled into the situation and have to step away from real work.

Everyone rowing in the same direction

On this note, another flag to raise is that disconnected toolchains often equal disconnected teams. The planning, development and testing teams can lack cohesion, and the release and operations teams often struggle to be on the same page.

Each group has its own tools, management and priorities; however, they need to be able to effectively communicate to ensure a smooth process. In an ideal situation, planning initiatives would flow into features for the development and testing team, which would flow into release pipelines and operational changes. Every team will always speak its own language, but the tools need to be interconnected and unify the teams in order to meet overarching goals.

Embracing a hybrid world

The term ‘hybrid’ is possibly the most used phrase in the software development space. Hybrid methodology specifically looks at to combining waterfall, agile and DevOps practices. Hybrid environments on the other hand mean your environment is housed in multiple locations such as the cloud, on-premises, virtual or code. There’s also hybrid geography, hybrid architecture, hybrid style, and the list goes on and on.

The key to embracing DevOps is properly managing all these variations on hybrid. If you can’t manage hybrid delivery, your whole delivery is in jeopardy, meaning you can’t improve your delivery holistically. Organisations must learn to manage a hybrid delivery world and be able to handle cloud and on-premises, as well as globally dispersed teams.

Focusing on the right things

The Theory of Constraints is about identifying the bottlenecks in your process and remedying them. Any work that’s not focused on eliminating the constraint will not result in improvement and could be considered a waste of time.

It’s important to keep in mind that if you haven’t unclogged the bottleneck, it will be hard to see any improvement. At the same time, focusing on the easy things that are non-constraints and automating those could be seen as a waste of effort as it never needed improving in the first place.

DevOps does not equal automation; it is important to remember this. If an organisation has confusing processes and automates them, they will simply be left with confusing automation. Organisations should focus on automating their constraints, minimising bottleneck and focusing on measured improvement.