Release management through the eyes of DevOps


To improve profitability, organizations need a process in place designed to manage and schedule the deployment of critical software updates and releases into the production environment – ​​this is where release management comes in. .

Versioning is introduced to troubleshoot, but it needs to be approached in the right way to be successful effectively. Many of the challenges companies face with their software releases in traditional operating environments stem from a disconnect between development and IT operations teams. To bring these two different sides together, many have implemented a DevOps methodology as a way to break down existing silos and deliver more value faster and with less risk by balancing throughput and stability.

DevOps, coupled with an Agile approach, helps teams work on smaller sections of code at all times, ensuring faster feedback. Risk is reduced because feedback helps resolve issues faster and there are fewer handoffs between teams. This means the software is delivered faster overall. Breaking down work into smaller sections also reduces the size of the release event – companies can do continuous delivery rather than what’s traditionally known as “release weekends”, in which many more releases important ones would be delivered over the course of a weekend. In contrast, regularly releasing small sections of new code makes the process easier – it becomes like breathing, something that is simply part of your daily routine.

Because of this change in methodology, DevOps and Agile are designed to create more sustainable long-term work environments by reducing the employee burnout that existing practices can lead to. To successfully implement these changes in a business and to help your employees embrace the changes, there are five key steps that team leaders can prioritize to turn this ideal into reality.

  1. Make sure everyone understands the jargon

Whenever a company implements a new process, approach or methodology, it is essential that everyone involved in the change – from those actively working on it to the most senior leaders who need to assess its progress – understand the new terminology. A special distinction should be made between the terms “deploy” and “release”: usually the new version is prepared, deployed to production and finally released for users.

The exact differences between these words will likely become somewhat fuzzy as teams become familiar with the DevOps and Agile approach, but especially in the beginning, having clear definitions that everyone learns and understands is invaluable. New vocabulary will develop as DevOps is implemented more widely across the enterprise, and therefore proactive learning among employees should be encouraged to minimize or, better yet, eliminate confusion.

  1. Limit changes to limit risks

The habit of deploying large chunks of code all at once doesn’t match DevOps, where the emphasis is on “little and often”. Larger-scale releases come with increased risk and they also force people to spend time managing complex release date schedules. Development teams are forced to wait for the next release date before they can deploy to production for the client build, which slows everything down.

In their book Accelerate on ‘Building and Scaling High Performing Technology Organizations’, Nicole Forsgren, Jez Humble and Gene Kim point out that “reducing batch sizes reduces cycle times and flow variability, speeds up feedback, reduces risk and costs overhead, improves efficiency, increases motivation and urgency, and reduces cost and lead time growth.”

  1. Bring value streams to the fore

Breaking down existing silos is crucial to accelerating the time from the initial idea to its realization. Having a defined, cross-functional, self-directed team that is assigned to a specific product or service (i.e., value stream) ensures that everyone who is required to maintain the value stream is part of of the team and move it forward. Identifying the value stream and the team responsible for working on it allows you to map the value stream.

Value stream mapping is important because it helps teams understand the value stream and where they can make adjustments to improve the end result for the customer. Trying to handle this manually would waste time and resources unnecessarily. Each value stream team can focus on their own improvements as needed, as well as judge their own performance and progress toward meeting business goals.

  1. Use VSM to improve flow

The initial emergence of the CICD (continuous integration, continuous delivery) pipeline allowed teams to test their code and fail earlier than ever in the process. Orchestration tools have also become available to ensure consistency of environment provisioning with cloud technologies. The result of these changes is more consistent releases based on a set model, which are predictable and reduce risk.

If companies can implement an end-to-end CICD pipeline or DevOps toolchain that automates the flow of value while providing continuous feedback, traceability, and continuous compliance, teams can benefit from advanced visibility across the entire value journey. Adding automation ensures that thorough testing can be done sooner, giving teams more confidence in the release when it is finally released to users.

One of the remaining challenges is pulling insights from the DevOps toolchain, which can lead teams to consider manual interventions or, if possible, a custom dashboard that can pull the data for them. A value stream management platform is a better solution because it can tie together the entire DevOps toolchain to unify the value stream, allowing the value stream to be reviewed continuously with all new evaluated information and changes to improve the flow implemented in real time.

  1. Preparing for an incremental approach

When large legacy systems are made up of dependencies, teams have a harder time adopting a new approach. Tightly coupled systems prevent builds from being prepared and released incrementally, and instead force them to be built, tested, deployed, and released all at once. The solution is to design loosely coupled systems that allow teams to focus on the current release and make independent changes as needed.

The possibilities of DevOps are constantly increasing. Release management has long been a manual and tedious process, simply because of the capabilities that were previously available to teams. Now that new methods and tools are becoming more prevalent, companies can accelerate their software releases without compromising quality – in fact, quality is improved while risk is reduced – meaning customers receive upgrades. day so often that they become a natural part of life. .

Image credit: Sergei Nivens / Shutterstock

Bob Davis is CMO at Plutorus


Comments are closed.