Release management through the eyes of DevOps
To drive cost efficiency, organizations need a process in place designed to manage and schedule the rollout of mission-critical software updates and releases to the production environment -- this is where release management comes into play.
Release management is introduced to solve problems, but it must be approached in the right way to succeed effectively. Many of the challenges that businesses face with their software releases in traditional operating environments stem from a disconnect between the development and IT operations teams. To bring these two differing sides together, many have implemented a DevOps methodology as a way to break down the existing silos and provide more value quicker and with fewer risks by balancing throughput and stability.
DevOps, together with an Agile approach, helps teams work on smaller sections of code at any one time, ensuring that feedback is faster. Risks are reduced because feedback helps resolve issues more quickly and there are fewer handoffs between teams. This means software is delivered faster overall. Breaking down the work into smaller sections also reduces the size of the release event -- businesses can carry out continuous delivery rather than what are traditionally known as 'release weekends', wherein many larger releases would be delivered over a weekend. In contrast, releasing smaller sections of new code regularly makes the process easier -- it becomes just like breathing, something that is simply a part of your everyday routine.
Because of this change in methodology, DevOps and Agile are designed to build work environments that are more viable long-term by reducing the employee burnout that existing practices can lead to. To implement these changes successfully 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.
- Ensure everyone understands the lingo
Whenever a business implements a new process, approach, or methodology, it’s vital that everyone involved with the change -- from those actively working on it to the more senior leaders who must review its progress -- understands the new terminology. One particular distinction that must be made is between the terms 'deploy' and 'release': typically, the new release is prepared, deployed to production, and finally released to users.
The exact differences between these words will likely become somewhat blurred as teams become more comfortable with the DevOps and Agile approach, but especially at the outset it’s invaluable to have clear definitions that everyone learns and understands. New vocabulary will develop as DevOps is implemented more widely throughout the business, and therefore proactive learning amongst employees should be encouraged to minimize or -- better yet, eliminate -- confusion.
- Keep changes small to keep risks low
The habit of deploying large bundles of code in one go doesn’t align with DevOps, where the focus is on 'little and often'. Larger scale releases come with increased risk, and they also require people to spend time managing the complex schedules of release dates. Development teams are forced to wait until the next release date before they can carry out the deployment to production for the customer release, slowing everything down.
In their book Accelerate on 'Building and Scaling High Performing Technology Organizations', Nicole Forsgren, Jez Humble, and Gene Kim emphasise that "Reducing batch sizes reduces cycle times and variability in flow, accelerates feedback, reduces risk and overhead, improves efficiency, increases motivation and urgency, and reduces costs and schedule growth."
- Put value streams front and center
Removing any existing silos is crucial to speeding up the time taken between the initial idea and its realization. Having a set team that is multi-functional and autonomous, that is assigned to work on a specific product or service (i.e. a value stream) ensures that everyone who is required to keep the value flowing is on the team and driving it forward. Identifying the value stream and the team that is responsible for working on it thereby enables you to map the value stream.
Mapping the value stream is important because it helps teams to understand the flow of value and where they can make adjustments to improve the end result for the customer. Trying to manage this manually would unnecessarily use up time and resources. Each value stream team can focus on their own improvements wherever necessary, as well as judging their own performance and progress towards complying with the business’ goals.
- Utilise VSM to improve flow
The initial emergence of the CICD (Continuous Integration, Continuous Delivery) pipeline provided teams with the ability to test their code, and fail, earlier in the process than ever before. Orchestration tools also became available to ensure consistency in environment provisioning with cloud technologies. The result of these changes is more consistent releases based on a set template, that are predictable and reduce the risk involved.
If businesses can implement a CICD pipeline or an end-to-end DevOps toolchain that automates the value stream at the same time as providing continuous feedback, traceability, and continuous compliance, teams can benefit from advanced visibility over the entire value journey. Adding in automation ensures that extensive testing can be carried out earlier, giving teams more confidence in the release when it’s finally pushed out to users.
One of the challenges that remains is extracting insights from the DevOps toolchain, which can lead to teams considering manual interventions or, if possible, a custom-built dashboard that can pull the data for them. A value stream management platform is a better solution as it can link together the entire DevOps toolchain to unify the value stream, allowing the value flow to be continuously reviewed with any new insights evaluated and changes to improve the flow implemented in real time.
- Prepare for an incremental approach
When large existing systems consist of dependencies, teams have a harder time adopting a fresh approach. Tightly-coupled systems prevent releases being prepared and released incrementally, and instead forces them to be built, tested, deployed, and released in one go. The solution is to architect loosely-coupled systems that enable teams to focus on the release at hand and make independent changes wherever necessary.
The possibilities of DevOps are continually rising. Release management has long been a manual and drawn out process, simply due to the capabilities that were previously available to teams. Now that newer methods and tools are becoming more widespread, businesses can accelerate their software releases without compromising on quality -- in fact, quality is improved while risk is reduced -- meaning that customers receive updates so often that they become a natural part of life.
Image Credit: Sergey Nivens / Shutterstock
Bob Davis is CMO at Plutora