Automation Opportunities in Agile Release Management

Software release management is all about controlling the release process to enable organizations to deliver quality software products in a timely manner. Application delivery is a complex endeavor that involves various stakeholders, including product managers, developers, testers, build and release engineers, senior management, and the operations team, among others. These teams employ various and disparate toolsets for issue tracking, version control, continuous integration, and infrastructure management. Sometimes these tools are specific to one subteam, and other times they are shared across teams.

As a result of the complex and nonstandard configurations necessary for different project types, project costs must include major time components devoted to managing and synchronizing the tools, communication between the stakeholders, and managing the testing environments. This burden is further exacerbated by the fact that each stakeholder has concerns pertaining to his or her local role in the release process.

This article describes proven practices for agile development teams. These practices, including continuous deployment and continuous delivery, take on increased value alongside the more traditionally important continuous integration. Continuous integration is usually used for the integration of development changes within the codebase mainline and testing for early bugs, while continuous deployment to user spaces is for testing and deployment of pretested code into the production environment. In projects I am working on, we have some integration among the issue tracking system, version control systems (VCS), and the continuous integration servers.

Continuous integration and continuous delivery require that some platform-level automation already exists, but there is still plenty of opportunity for additional application deployment automation. Apart from that, there is ample space for automation while integrating the independent tools in a much tighter fashion.

Hurdles in Release Management

Getting a planned release delivered on time is the largest concern for development organizations, though there are several potential major hiccups that can prevent accomplishing this. During the planning of a release, teams need to make some rather basic but still very important decisions, like which prereleased version will be used as a base version for a release, what new features or improvements will be handled in the new release, and how to keep all product managers appraised of the release scope. This creates major and redundant discussions in an organization across the many functional teams.

Most important is providing a robust VCS for development along with document management to manage release notes, test cases, and other essential documents. Version control tools must be capable of managing variants in the code using branches, metadata for branches, and creation of pull requests (to indicate a merge may be required). All these procedures need to be uniform across the complete development cycle for a release, which rarely can be handled successfully in a manual process. Unfortunately, even one error in any of the tasks creates cascading effects that are cumbersome to recover from.

Once development is completed, code conflict is often the next potential major setback for developers. Because they are not informed about changes on the parent branch in the VCS unless they are ready for their code to be published or merged, developers usually struggle with code conflicts and resolving them. This usually is more headache than actual development because it involves searching for minor inconsistencies as opposed to developing new features.

Managing the testing environments across the organization for a release is another nightmare. It’s necessary to have complex infrastructure management when tracking the environments already in use, determining which ones can be used for the upcoming release, and doing so while addressing any run-time change that may exist in environments due to a technical glitch in the current release.

Although testing environments are usually controlled for a release, any unplanned change in the environment can impact deployment automation. Preventing these incidents would either require configuration changes on the continuous integration tools or the unfortunate workaround of returning to manual deployment. In either case, these changes are expensive because configuration changes are time-consuming, and manual intervention is less reliable and creates unexpected errors.

In the agile world, the scope of a release is locked in. Changes, even at the last minute, need to be addressed without overshooting the release date or compromising the incorporated functions. Scope change (either inclusion or exclusion) of a single feature would turn the VCS upside down. For organizations, the creation of a new release is simpler than making a scope change in the current release, which is not always feasible.

Finally, communication between various teams and senior management is always a source of confusion. The teams are often not on the same page when it comes to the release status, which means that management gets conflicting messages. This creates chaos and ends in meaningless argument, misunderstanding, “the blame game,” and, worse, project failure.

Every Problem Has Its Own Solution

Though the problems discussed above are major ones, they can be handled. Control can be achieved by integrating an issue-tracking system, VCS, and continuous integration system and implementing automation at all possible levels and connections. This solution doesn't have to restrict teams to a particular provider, only to setting up properly first.

By taking advantage of the capabilities of issue-tracking systems, and with some automation of version control systems, it is possible to track all the prereleased versions of a project. Additionally, utilizing agile boards as part of issue-tracking systems helps keep the release manager and product managers on the same page. The VCS can be automated to create a release branch from a specified base release using standardized nomenclature, which eases the release-planning process at its top level.

Next, VCS-related problems can be addressed by automating issue-tracking workflow transitions such as cloning the repository, the creation of developer branches, and the creation of pull requests once development is done. Basically, progress is made using an abstraction of VCS activities so that developers can concentrate more on actual development.

Additional gains can be found in automating the branching and merging process so that developers are well informed of any changes to the parent branch they are working on. Keeping developers apprised of this will decrease the probability of conflicts during code merges. Merging of the developer branch is done after the testing of the developed code, which ensures teams always have thoroughly tested code before merging.

Maintaining the details of the testing environments in the issue-tracking system and integrating it with the release projects drives the way for automatic deployment from the continuous integration server, using up-to-date information from the issue-tracking system into the required specific environment. Any dynamic change in the deployment environment details can be easily addressed without any configuration change or manual trigger in a continuous integration system. By automating the VCS branch merging and demerging process, teams gain the ability to ensure that any last-minute scope changes can be addressed. This automation can be incorporated in the issue-tracking system workflow so that any inclusion and exclusion of a feature from a release can be handled by the click of a radio button.

Because the release management tools are tightly integrated, the complete status of the release and development can be viewed on the release dashboard and Scrum board of the issue-tracking system, while the complete summary of the issue would be updated on the issue tracking system. All the stakeholders are on the same page!

The level of automation highlighted above paves the way for a smooth and happy agile release management process. Although not every operation across tools can be fully automated, there is ample opportunity for automation to help teams improve their processes and procedures.