Low-risk releases: 5 steps to building a leading DevOps practice

For years, software teams have been mired in delays. And here’s the thing: The coding speed of developers hasn’t been the main issue. The longest hang ups have always been with getting code through approvals, testing and integration. As a result, companies have been releasing software with massive feature updates in large chunks on a monthly or yearly cycle. That’s been the standard, until DevOps came along.

With the constant change in the tech landscape, DevOps methodologies have taken off—and out of necessity. Fast-moving organizations use DevOps to release features and fix bugs faster. Startups leverage these techniques to go to market quicker and catch up to the "big players" in less time. And in that way, DevOps is as much a business development strategy as it is a software development strategy. 

Consumers see the direct benefits of DevOps and now expect a flow of small feature releases instead of large overhauls. Because of that, companies feel added pressure to keep release pace with their competitors. The goal of DevOps isn’t speed for speed’s sake. The goal is production and value above all else. To succeed in DevOps, you need to examine the entire software life cycle and think of it as a system, a factory that produces software features.

Imagine a factory. Instead of producing a physical product as a factory would, you’re producing features. Ideas come in and features go out. Your idea moves down the conveyor belt as it's assembled, tested, packaged and delivered to your customer. Your goal is to optimize the entire production process. But how can you use DevOps (and the Lean principles it's rooted in) to improve your software factory? Here’s how:

1. Reduce your batch size. A key principle of the Lean methodology is eliminating waste and reducing work-in-progress. Instead of a large set of features and changes, your releases should be a single, small feature or change. Each update should be as small as possible.
   
   This requires a large culture change, and you may encounter a lot of pushback on it, even from your developers. For decades, a “software release” was synonymous with a large set of drastic changes; the underlying assumption was that the more improvements and changes made through each release, the better the release was. Unfortunately, there are still developers who feel it’s a waste of time to go through an integration and deployment process for a single small change. Getting everyone on board with doing something a new way can be hard, so be patient.
   
   
2. Create high-fidelity environments. Lean promotes building quality into the process by automating and standardizing tedious, repeatable tasks. Developers and testers must be able to create servers configured exactly as they are in production, and they need to create it from an automated process without permission from IT.
   
   This requires a mindset shift in your IS/IT department. Many IS/IT teams don’t like allowing developers to spin up any server they want. Careless creation of machines can cause issues with resource availability and costs. To overcome these roadblocks, you need to establish trust between your departments for this to work. Create standards and procedures that mitigate the risk of developers creating their own environments. Put safeguards in place where you can and let them be autonomous.
   
   
3. Automate integration. Continuous integration (CI) gets a lot of attention in the DevOps world because it focuses on delivering fast. Developers should be able to commit their code and have it whisked away, built and pushed to an environment. But even with all the speed it can produce, CI also has enormous potential to be the biggest bottleneck.
   
   The resistance you may face in automating integration will likely not come from humans. The biggest challenges lie in technical hurdles and legacy software that doesn't want to play nice with newer methods like DevOps. Create an integration plan, and start by integrating the smaller applications that have importance to the company but are less effort to integrate. This will help your team learn more about the integration process and perfect it before taking on the large projects.
   
   
4. Automate deployment. Another way to deliver fast is to automate deployment. Your developers need to deploy approved software changes quickly and without incident. Having smaller batch sizes will help with that, as your batch size has a direct correlation with the deployment risk. Deploying a software change should be a non-event.
   
   The biggest hurdle to deployment automation will be within your infrastructure and security teams. Experienced IT pros struggle with the idea of pushing out changes every day because deployments used to be such a major event (sometimes even filled with cake, pizza and a big celebration). Additionally, automating effectively while maintaining a high standard of security may need a DevSecOps approach, which is also something new to consider for your security team. But by making changes small and frequent over time, it becomes far less scary.
   
   
5. Automate as much testing as possible. The goal here, also grounded in Lean philosophy, is to reduce waste. Your testers should spend their time building and refining their tests, not running them. Tests should be automated, and you should treat configuration for these tests as source code. Your tests should run as soon as new artifacts are approved and pushed to test. Certain user interfaces or projects that require unique inputs may still need that human touch, but the majority should be very hands off.
   
   You will encounter the least amount of friction implementing this step because most testers would rather spend their time creatively building and refining tests. Give them time and autonomy to do it.

Just because DevOps is a better way of working doesn’t mean everyone who’s trying it is executing at a high level.

Many companies, for example, take a “tool-first” approach to DevOps transformations. They buy fancy new automation tools or try to fit containers into their existing workflow. But throwing new technology at a poor software development process won’t solve any problems. Without drastic process change, you won't get different results.

Companies struggling with DevOps adoption today are hampered by bottlenecks in their process, usually the same ones that existed before they started DevOps. They include:

• Waiting for the creation of testing or hosting environments

• Approval time (testing, provisioning or business rules)

• Wait times during rework and regressions

Software alone can't solve these problems. Even after the expected delays from introducing, training and integrating new tech, companies that took the “tool-first” approach see similar (or even degraded) performance. The bottom line: No matter how fluid and fast your software infrastructure is, if a code commit is waiting for a week to for testing your pipeline is idle.

To remain competitive in today's market, you need to be moving faster and with fewer errors than your competitor. By mapping your value stream as a system focused on output, you can find the true development problems and address them. 

DevOps is an all-in approach. Picking one or two things and automating them won’t magically increase your output. You need to map your value stream and make adjustments to each system to establish a smooth flow.

The adjustments you make will not be “one and done.” Give attention to learning from the process and make changes based on what you learn. Approach the adjustments with a hypothesis and test it, and share the results with the team. The overall goal of Lean and the foundation of a quality DevOps practice, which will allow you to iterate to perfection, is a culture of experimenting and sharing.