The disruption caused by DevOps is most obvious in how teams adopt release management. Teams can’t even agree on the definition of “release”!
Although agile teams often preach that “deploy continuously and release on demand” is clever and logical, there is much to be said for using some of the old practices like change-advisory boards and checklists to manage the process of moving something into production.
With the increased focus on preventing supply chain threats and other security vulnerabilities, this is magnified. Here’s everything you need to know about the old and new colliding, including how to get the best of both worlds.
Clarify what you’re talking about
To begin, a few words about terminology: Typically, releasing something means making it available to whoever requested it, whether it’s a program or a feature.
If you’re not working in a DevOps environment, a development team is “releasing” what they’ve built to the operations team. A release is when the operations team makes the app, service, or feature available in a DevOps environment or when you think of releases from the perspective of end-users of a digital solution.
The process of going from the dev cycle to the ops cycle is referred to as “deployment” by a DevOps team. This is not what a DevOps person would call releasing. Release, according to that person, occurs after deployment, when users are onboarded with the new features that were deployed.
Many of the problems I observe are caused by a lack of understanding and appreciation of the above two points of view. The discrepancy is depicted in the diagram below.
There is rigorous control between dev and ops in traditional release management. Consumers of the service have implicit access to anything that operations have deployed in production, and any difficulties are handled by support.
In DevOps, on the other hand, the same team is responsible for both development and operations, so deployment is only one of the team’s many responsibilities, and it happens all the time. The DevOps team, on the other hand, will carefully prepare how to make new features available and, if any issues arise, will limit the number of users until all issues are resolved.
The benefits of release control
The fundamental goal of the release control function is to guarantee that anything released into production is “fit for purpose,” whether it’s new functionality, simple tweaks, or entirely new systems.
- These are the questions that most operations teams are concerned with:
- Are we going to break something that’s already working?
- Is the release going to be safe?
- Is the release being managed by operations?
- Is the release ready in terms of performance and all other nonfunctional aspects?
- Is documentation of all linked artifacts, such as training, in place, and are known errors understood?
The benefits of releasing on demand
Traditional operations teams usually struggle with deploying new features in a controlled manner, which is what the DevOps team is doing. New functions will be tested and scaled up to everyone only after they have been proven to work. In fact, because the capacity to make controlled releases to users is dependent on capabilities in the produced code, this is likely only possible if there is a close link between development and operations.
The advantages are enormous, as anyone who has tried to manage software upgrades with a big user base can attest. No amount of preproduction or acceptability testing can uncover all of the problems that will inevitably arise in production.
The best approach: Practice agile and automate
DevOps teams that are well-implemented can be much more productive and create a higher-quality product than traditional IT setups where development and operations are separated. If you are not a greenfield company, however, this constitutes a huge culture shift, and many legacy programs are difficult to convert to this new paradigm.
“I need a release control mechanism between what the developer is doing and what I’m doing,” the ops guys will typically say. This is an indication of a lack of faith. Instead of discarding standard release controls, use this as a chance for developers to automate as much of them as feasible. And it’s great if developers name it “deployment controls” or “pipeline checkpoints”—that’s the same thing.
Ops, on the other hand, may teach some methods, such as how to leverage service catalogs to expose new features and govern their delivery to consumers. Service catalogs, service subscriptions, and contract-based support are all familiar territory for operations teams. This can be used to improve the current DevOps approach of controlling the rollout behind the scenes based on release flags and other factors.
This method of merging the best of both worlds is being included in the future IT4IT standard, with new value streams handling deployment and release separately. The blue value stream arrows below clearly demonstrate this:
Another reason to keep some of the previous release control attributes while transitioning to a more agile methodology is to automate and codify tacit knowledge.
It’s vital to be able to reconstruct anything and know what a release’s content is so that you can perform an audit and examine the security controls. This is why your releases must be centralized and managed by the entire IT organization, not just the DevOps team.
They must be aware of the processes involved in production. If IT fails to do so, the organization may be exposed to a security risk.
Finally, if a release isn’t clearly documented and standardized, it’ll be difficult to resurrect a DevOps team years later when a product or service that has been neglected for a long time requires fresh improvements.
Best practices of good release management
So, which method is the best? Certainly, we as an industry are moving toward continuous-release, but there are gray areas in the real world, and the solution must account for them.
Your systems may be stable, but they may require modest adjustments. When problems arise, though, someone must take action.
This is why having centralized management and knowing what the prior team put into production is critical. It becomes very impossible for a new DevOps team to handle something without introducing problems if each DevOps team has its own pipeline and procedures for managing operations.
The following is how you should handle the transition from development to operations:
- Ensure that everything that goes into production (and, if applicable, preproduction and system testing) is properly defined and repeatable across time.
- Maintain good records on release/deployment artifacts such as binaries, release notes, configuration scripts, and a list of known failures. When it comes to replicating complete sets of assets, tacit knowledge is frequently used.
- Examine your supply chain. Are there any certified assets in the built release? (That is, it was guaranteed to be supplied by the anticipated source.) This is usually accomplished through the use of code signing and excellent procedures.)
- Defend against deliberate or careless release errors. To protect against inside risks, make sure there is always more than one person involved in new deployments.
- Ascertain that the code has been scanned prior to release, preferably in a “shift-left” way to avoid a last-minute, blocking operation.
- Automated functional and nonfunctional testing with risk scores is available. This allows you to analyze the release candidate quickly and continually.
Stick to your principles, but automate
Please don’t toss the baby out with the bathwater. In IT management, adhere to all of the standard release control concepts. Learn from them because many of them are still relevant. DevOps teams should, nevertheless, make every effort to automate as much as feasible.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html