Introduction

Nowadays, I often hear that the Release Manager role is non-existent due to the advent and rapid adoption of DevOps culture. This is a major misconception – the role of the Release Manager has shifted from the traditional; like many other things in the rapidly changing technology scenario.

The Release Manager role is an important role in the sense that it enables all the hard work put in by the development teams, analysts and architects, seethe light of the day, i.e. they help make the project go live. Without an effective Release Manager in place, business objectives will never be met, no matter how skilled your development team is.

In the Q&A section below, the ‘traditional’ release management concepts have been blended with the DevOps philosophies, ensuring that the reader gets ample exposure to understanding the role better.

1. What is release and deployment management all about?

The purpose of release and deployment management is to define and agree to release and deployment plans with the relevant stakeholders and customers. During the release and deployment activities, release managers need to ensure that the changes, being released and deployed, are properly managed. They also record and manage any risks and issues that are related to the new service or the changed service which has been implemented.

Before the release happens, the release and deployment management personnel must ensure that the assets that are being released have been recorded accurately in the configuration management system and they are compatible with each other as a single unit, so that they can produce the desired results when they are out in production. If there are any adverse effects of releasing a package, a backout plan must be devised and executed. The backout plan is also called the rollback plan and must be prepared before the release happens.

Release and deployment management is also responsible to ensure that customers and users can use the newly deployed or modified system as expected. The operations and support staff that will maintain the new system in the future must also be able to do so. Both of these require knowledge transfer from the implementation team.

After every release happens, there is usually a period of warranty. The release and deployment team are available during this period to monitor and take appropriate action, if any adverse impact of the new or modified components is noticed. During this period, the release and deployment team will take help from the change management and development teams to be able to make tweaks without impacting the essential functionality.

2. What is the unit of release?

Release in IT refers to a portion of a service or an IT infrastructure that is released for consumption by the users and customers. Release unit will contain multiple components and configurations that have been modified, as a part of Change management, and will provide some additional or different functionality of the system. Release unit may contain one or many packages depending on the extent of the impact. If the change being implemented spans across multiple technologies, there may be different technology-wise packages that implement this change.

Large changes are usually implemented in smaller chunks over time. Each of these changes may also be called a unit of release. The timing and functionality delivered through each unit is determined as a part of release planning. Release unit levels must be appropriate and will depend on what is being released. There is usually a release policy in every organisation. e.g., for a website, the release level maybe tied with the UI or web pages. Another way to design release levels would be to segregate by use case e.g.- search a product functionality.

While determining release units, one of the most important factors to consider is the amount of change required to deploy it. The amount of resources and time needed to build, test, distribute and implement the unit must also be considered. The complexity of the interface between the new unit and the rest of the unchanged system is also a factor that could determine what is defined as a unit. There could also be capacity considerations, business considerations such as business peak seasons that determine what could possibly be release unit.

3. What is the release and deployment model?

In the service design phase, the most suitable release and deployment models will be selected. This will include the approach, mechanism, processes and resources required to build and deploy the release in a timely manner and within budget. It must be kept in mind that after the initial release, all the successive releases will be on a system that is already live. Adequate care has to be taken not to disrupt the services that are already being consumed by the users and customers. This requires very detailed and careful planning, and this is where, having a release and deployment model helps to standardise the way changes are implemented on a live system without causing any disruption.

Release and deployment model will define the release structure for building a release package and the target environments. It will also define the exit and entry criteria including deliverables that must be delivered and those that can be delivered at a later release. Since every release will add or modify the functionality, documentation must also be released together with the configuration items. This is especially important if services are being consumed by users who are not tech savvy, like the booking clerk at the railway reservation counter.

Releases pass through the service transition phase via multiple environments such as development, testing, integration, staging and then finally into production. The deployment model should contain details on not only the physical and logical environments, but also show the activities that can be performed at each level or environment. Each environment should add value to the product being released.

4. What are the factors that you will consider when designing release and deployment model?

Release and deployment model must consider including activities that verify the COMPLIANCE of a release with the related standards, enterprise architecture and any other user-centric factors like usability. There should also be activities to ensure the integrity of hardware and software. Sufficient regression testing must be conducted, and results of this test must be verified. Whenever possible, the delivery distribution, installation build and configuration steps should be automated. Many activities for the release will be same across many releases and therefore costly manual labour should be avoided whenever possible. This may require some investment.

Managing software licences should also be included when designing the release and deployment model. Licences that have expired or need to be renewed must also follow this model. Rollback strategies for the creation of a backup plan irrespective of the size of the release unit must be included as a mandatory task in the model. Documentation is another important aspect that must be included in the model. Documentation related to the release and deployment steps, target environment, troubleshooting guides, release notes must accompany every release that is being made irrespective of the size of the release unit.

The existence of a release and deployment model is important for such businesses that frequently go through change and make releases.

5. What does a build manager do?

A build manager performs the release packaging and making of the build, establishes the final release configuration which includes the software, hardware, infrastructure and all the associated information related to this and the knowledge that must be passed on to the operations team. He/she will then build the final release delivery and conduct smoke test before declaring the release to be usable in the environment. Build activities are carried out by the build manager for every environment i.e. test, integration, staging and production.

No release is likely to be perfect. Therefore, the build manager must also document the known errors that are being introduced together with the release. E.g., when deploying a build into the staging environment, he/she may declare that there are five low priority bugs that are undergoing fix by the development team and in the next build, these will be rectified. If, due to time pressure, a build must be released even with blockers. The bugs will be documented in the release notes and the build manager is also responsible for providing a workaround as to how to live with the bugs till the time they get fixed.

When the build is finally released into production and handed over to the operations team, the build manager provides inputs to the formal sign-off and handover process. Throughout the process, the build manager must interface with the other process owners such as information security, testing, change management, service asset and configuration management, capacity management, availability management, incident management and quality Management.

6. In the era of DevOps do you really need to have Release Managers?

DevOps is the streamlining of the activities surrounding IT solution development (dev) and IT operations (ops).

Release management entails planning, scheduling, and controlling a software build through different stages and environments.

In many cases, release managers are the gatekeepers of the change management process, ensuring that production deployments are well orchestrated and follow all the necessary steps for proper visibility and approvals are obtained throughout the process.

As companies look to adopt a DevOps philosophy, the role of release management must shift as well. In DevOps, teams take control over production deployments. The team is not just focused on creating working code, but also on the infrastructure, network, and other implementation items necessary to get the code into production. By having this accountability, teams will create code with higher quality, making production systems more reliable and maintainable.

Having change orders or some record of change is still needed in DevOps. These are not only needed in regulated environments to show traceability from code to deployment, but these also shed light on release volumes and time-to-market metrics, which are core to measuring DevOps maturity. However, there will be some change in the information captured in change orders. There will no longer be a need to track implementation or back-out plans as part of change orders. One just needs to track the application, its components, and its promotion schedule.

The key to MAINTAINING these change orders is AUTOMATION. Continuous integration pipeline should have the ability to communicate with change order system such that self-documentation can occur.

One of the biggest opportunities with release management being enabled via a tool is that it can integrate audit and security requirements into the process. Rather than doing post-release audits, one can use a suitable tool to integrate these controls as part of the pipeline.

As we can see from the above, release management is still critical in a DevOps environment. The function must drive the shift from a service-based organization to an engineering group that enables frictionless flow to production.

7. As a Release Manager, what are the DevOps terminology you know about?

• DevOps refers to a dynamic relationship between software development and other ITdepartments like operations, security, testing. The goal of DevOps is to change and improve the relationship by emphasizing better communication and collaboration between the two. It aims at establishing a culture and environment where software releases can happen frequently and more reliably. The DevOps allows teams to react to business opportunities in a timely manner. For example, Amazon Web Services deploys software updates every 11.7 seconds.
• Continuous Integration (CI) is a development practice wherein developers integrate their code into a shared repository regularly and frequently. An automated build – typically via a Continuous Integration system – verifies the code and allows errors to be detected early.
• Continuous testing (CT) is a process that uses automated testing in order to gain immediate feedback on the business risks associated with a software release candidate. Automated testing is an integral part of CT. Automated testing refers to the detection process for software issues and defect prevention, whereas Continuous Testing addresses the wider challenge of IMPROVING the effectiveness of these detection sensors.
• Continuous monitoring is the process and technology used to detect compliance and risk / issues associated with an organization’s operational environment. The operational environment consists of people, processes, and systems working together to support efficient and effective operations.
• Continuous delivery describes the ability to get new features, bug fixes, configuration changesinto the hands of users quickly and in a reliable, replicable way. Continuous delivery is focused on automating delivery by using tools to execute various processes.

8. Have you heard of Scrum Release planning? What is it?

A very high-level plan for multiple Sprints (e.g. three to twelve iteration) is created during the release planning. It acts as a guideline that reflects expectations about which features will be implemented and when they are completed. It also serves as a base to monitor progress within the project. Releases can be intermediate deliveries done during the project or can be final delivery at the end.

To create a release plan, the following things must be available:

• A prioritized and estimated Scrum Product Backlog
• Estimated velocity of the Scrum Team
• Conditions of satisfaction (goals for the schedule, scope, resources)

Depending on the type of project (feature-driven or schedule-driven) the release plan can be created in different ways:

• If the project is feature-driven, the sum of all features within a release can be divided by the expected velocity. This will then result in the number of sprints needed to complete the requested functionality.
• If the project is schedule-driven, one can simply multiply the velocity by the number of sprints, and this will give the total work that can be completed within the given timeline.

9. What are the sub-processes of ITIL® release management?

Release Management Support - provides guidelines and support for the deployment of Releases.

• Release Planning –assigns authorized changes to releases and defines the scope and content of releases. A schedule for building, testing and deploying the release will be developed in the release planning process.
• Release Build –issues all necessary work orders and purchase requests so that release component are either bought from outside vendors or developed/ customized in-house. At the end of this process, all required release components are ready to enter the testing phase.
• Release Deployment –deploys the release components into the live environment. This process is also responsible for training end-users and operating staff and circulating information/ documentation on the newly deployed release or the services it supports (e.g. release notes)
• Early Life Support –resolves operational issues quickly during an initial period after release deployment and to remove any remaining errors or deficiencies. This is also known as the hyper-care or the warranty phase.
• Release Closure –formally closes a release after VERIFYING whether activity logs and configuration management system contents are up to date.

In software engineering, a freeze is a period in the development process during which making changes to the source code or related resources become stricter or are prohibited. A freeze helps move the project forward, towards a release or the end of an iteration by reducing the scale or frequency of changes and may be used to help meet a product roadmap e.g. attaining a Minimum Viable Product (MVP).

The exact rules depend on the type of freeze and the development process in use; e.g., rules may include only allowing changes which fix bugs, or allowing changes only after thorough review by other members of the development team.

Common types of freezes are:

Specification freeze, in which the parties involved decide not to add any new requirement, specification, or feature to the feature list of a software project, in order to begin coding work.

Feature freeze, in which all work on adding new features is suspended, shifting the effort towards fixing bugs and improving the user experience. A feature freeze helps improve the program's stability and frees up manpower to work on the MVP. E.g., user interface feature freeze means no more features will be permitted to the user interface portion of the code; bugs can still be fixed.

Code freeze, in which no changes are permitted to a portion or the entirety of the program source code. Particularly in large software systems, any change to the source code may have unintended consequences, like introducing new bugs; these are often employed in the final stages of development, when a particular release or iteration is being tested, but may also be used to prevent changes to one portion of a program while another is undergoing development. Code freeze minimizes regression effects.