This article talks about what release management is, then tells you how to implement the concepts in an organization by explaining what skills are needed, how release managers work within a team, and how the process is related to continuous integration.
Release management combines quality assurance compliance activities with management of software artifacts in a central repository (source control), then releases those software artifacts to a client production environment for application deployment. The release could be done manually or automated, depending on the maturity of the release management processes.
It all started with the shift from project-based companies to product-based companies. For example, a company making websites for different clients sees that clients have started frequently asking for changes to their websites. One client wants the user to just be able to browse through their merchandise, while another client wants a more complex system where the user has a complete menu system to order every option and detail. Nearly all websites the company builds are different, yet they usually have some similarities, such as a top header, a navigation bar, something about the client’s product, and then some capability to attach a shopping cart or design a complete ordering system. So what arises from this challenge is a product-based website, which has all the same elements but with configurable mechanisms for deploying features as needed. This configuration part is the Holy Grail of release management.
Today it is common for every product to have a configuration ability built in. Android, for example, is highly customizable at many layers, including features for development, testing, and end usage. When all the products have configuration built into them, a central body is needed to ensure from beginning to end that requirements are made into a complete, sellable product. We also need to consider how these requirements are transformed to code, tested, verified against the requirements, and then packaged to be released to the customer in a production environment.
Release management provides these capabilties. It is the glue that holds all the key departments of a software development lifecycle together, including business and functional requirements, design, development, testing, deployment and ongoing maintenance.
The basic tenets of release management are as follows:
- Code management: Proper code management of multiple clients means they have administrative access to source code repositories and how they are managed. To some, configuration management could be a part of release management.
- Facilitation and collaboration: Release managers should be talking with all the people in a software shop and providing them with help or solving their problems related to release management.
- Processes and policies: With time, different anomalies will be detected. For any anomaly, it has to be properly detected and analyzed, and then some controls needs to be applied to it. That implementation of control will be applied by release managers by making policies and procedures to enforce some additional practices.
- Gatekeeper or guardian: Release managers are the gatekeepers to the production code. Any software code artifact that moves out of the organization has to be known to the release manager and should be approved by change management function.
- Metrics measurement and productivity: With time, different metrics and measurement should be collected to help understand the throughput of releases given that the organization has some measurable skill set of people, technology, and current mature processes.
The Reporting Line of Release Management
Release managers may report to different teams, depending on how big the organization is. The release managers may report to the head of quality assurance, the project management office, the head of product development, or even directly to the chief operations officer. These variations are basically dependent on what level of process maturity the organization is at. The more process maturity the organization has, the more likely the release management function will be autonomous and the release manager can exercise control in making policies and procedures.
Skills and Expertise Required for Release Management
Who is best suited for the job of release manager? Basically, very mature people who have had experience in nearly all the phases of the software development shop. They know the ins and outs of how and when process changes impact the working habits of personnel involved in software development.
They should be good at work management, time management, and, most of all, people management. They are more like project managers, but armed with a Swiss army knife of processes and automation of working habits. They are the people shaping the organization’s internal IT controls, strengthening them with automated solutions known as continuous integrations and continuous delivery. Technically, they have to be proficient in maintaining the source code repository, including branching, labeling, and extracting a particular release from repository when the code is ready to be built, packaged, and deployed.
In other words, they should be able to inform anyone at a moment’s notice where a particular artifact (be that a requirements document, functional specs, project schedule, design documents, QA plan, QA test suite, deployment plan, deployment manuals, user manuals, release plan, client service-level agreement, etc.) is residing in the code repository and who should have access to it. There are usually qualifications that decide whether a particular document is to be shared with a particular personnel level.
Release managers should not be like the old-school auditors who are very strict with policies and procedures and are only concerned with following rules, no matter how slow they make the software development. Release management supplements the role of auditors by enforcing controls, but it focuses on automating every aspect of software development in accordance with the policies of the company. There might be some areas where release management will take a firm stand, such as ensuring a code review before the code is checked in, and some areas where release management might relax, such as providing the development and QA engineers the freedom to work until the tasks and policies are automated and tested.
In some mature organizations, release management also will have the developers associate check-ins with at least one work item or issue reported so that a particular check-in or change set has visibility. They might relax about how QA makes their environment after a build is provided by the technology team in the beginning. They will automate the whole process so that when a developer checks in his code, making and deploying the build is performed. If a successful build is made, it is copied to the QA environment by some automated test quality gates to pass a sanity or smoke test. This whole process is also called continuous integration.
Application of Release Management Concepts
Most of what is discussed in the article is achievable. For example, Android is already using these practices. Mobile users automatically get over-the-air updates to their operating systems with new features, which are then deployed on their devices.
Tell me in the comments what you think of release management and how much release management is implemented in your organization.
User Comments
Thanks for your article.
I wonder whether you also need a release management function in an agile environment or even with continuous delivery. With a Definition of Done agreed by the team, the team is responsible and takes responsibility for releasing the proper stuff properly.
Thanks for your comments Frank.
While I agree to you over the comment, the Product Team's responsibility is to churn new versions of Product.
It will be responsibility of Release Team to release it to Public and to Production. RM works with four pillars, Change Management, Build Management, Deployment Management and Incident Management. With the Continous Integration and Delivery, one could get upto Deployment Management. There might be areas which needs to have an overview by incident management, that would be seen by Release Management.
In other words, even if one does automate fully towards Continous Integration / Delivery, one might still needs to have a Management or a body to oversee things in a Release Context.