8. Building a release management infrastructure

(Streamlining change control process and automation)

The release infrastructure covered the hardware, storage, network connections, bandwidth, software licenses, user profiles, and access permissions. Human services and skills were also part of the release infrastructure. For example, if a specialist software needed to be installed and configured, they could not exclude the availability or cost of getting such skills into the infrastructure plan.

It is critical to discover any hidden bottlenecks in procuring the required hardware or missing skills (e.g. configuration of secure networks). The team had to resolve these issues before delivery.

However, that standard was not easy to uphold. The team strove to get the release infrastructure in place as soon as they started on the project. Even after six weeks' lead time, however, they were still waiting on specialized memory and hard drives for the test servers.

Identification of automation tasks

The team identified the build and test tasks that could be automated, and came up with the criteria and definitions for normal, standard, and emergency changes. Automation enabled them to perform repetitive tasks without tying up valuable human resources. They also qualified a number of standard changes based on risk, repeatability, and time involved in execution.

Changes were bundled to align with the release cycle of two weeks. Change teams worked with the release and deployment teams synchronize with the release calendar, types of release, and early life cycle support.

Manual versus automated package

Prior to their involvement in the project, the engineering teams manually crafted deployable packages. Due to this, each new package was not guaranteed to be the same as the previous one. In fact, it was not guaranteed to even be the software they had been building, much less guaranteed to work! It often took the tech staff days to create a package with the features, in a structure that could be deployed.

Service acceptance and verification

The release management team immediately drew up a structure and service acceptance criteria for the deployable package the engineering team was delivering, and helped them standardize the packaging. This triggered the implementation of automated processes to build the software in that consistent structure for every release point.

As the team had automated the verification process of the acceptance criteria, the execution was guaranteed. For example, code must be unit tested prior to delivery and test deployed to ensure that it could be. As a result, the release management team was able to package, version, test, and deploy the finished code with a single command, in a very short time.

The new norm of release cycles

The newly established release cycle meant that a release had to be tested for regression, performance, and integration in just two weeks, for the team to be able to release it into production. The team was able to overcome different types of testing (integration and performance) by having separate environments for each type. However, the challenge of accommodating two months of regression testing into a two-week window seemed impossible. Here's how they did it.