DEVOPSdigest

Every business strives for cost-efficient and effective allocation of its resources. One of the most impactful ways to achieve that in our technology-based business environment is through the development, deployment and innovation of mission critical software. To do so, there needs to be a process in place for managing, planning and scheduling the rollout of IT services, updates and releases to the production environment.

Historically, when a new business project is the driver of new software releases, the development team creates release packages consisting of large bundles of new features, which they hand off to the IT operations team to deploy. Then, as a result of agile adoption, the development team continued to ramp up its release cadence.

Unfortunately, the IT operations team would not be prepared for an increase in releases, which could result in a number of problems:

■ The IT operations team not understanding the release package

■ Inconsistencies between pre-production and production environments

■ Too many components, resulting in low quality code

■ Integration issues with complex dependencies in tightly coupled systems

These issues can result in a lot of finger-pointing, complaining and frustrations between development teams and IT operations. Hence the need for release management.

Release Managers

When these issues did arise, the first response was traditionally to create a control to avoid repeating the problem in the future. While this approach did have some positive outcomes, it also created layers of bureaucracy and wait times.

This led to the introduction of the release manager. Release managers play a key role in supporting the value stream and are responsible for managing and coordinating the production, deployment and release processes. They handle all the paperwork, calendars, checklists, the change advisory or approval boards and all the small details needed to finish a new feature.

As the role evolved, it became clear that release managers and the process they're meant to support were creating bottlenecks. While bottlenecks can serve their purpose — in the case of governance and protecting the organization from disaster — the question became how to improve and expedite the process so value delivery could be increased and accelerated without compromising the risk mitigation.

Release weekends

Technologists' working environments have never been simple. The more complex and interdependent the systems are, the more fragile they become. This, coupled with time constraints that cause technical debt such as systems becoming increasingly legacy, creates even more unplanned work.

As software releases became bigger and more unpredictable, companies created release nights and release weekends. On these specific days, teams were required to work outside of normal hours to be at-the-ready when issues inevitably occurred.

Release nights and weekends were often like herding cats. Release managers tried to coordinate different teams in various locations to work together in an orchestrated manner. These specific release times were very stressful and often led to developer burnout.

Additionally, release nights and weekends created more risks for businesses. Besides the most common risk of deployment failure, teams also had to make sure not to miss maintenance windows — requesting more time to fix issues could result in a hefty fine as part of the customer SLA or from the regulator.

Release calendars

Release managers knew that these large, complex and interdependent releases were bound to have bugs and would need immediate attention. Therefore, it became the release manager's job to schedule releases in order to provide visibility into what was happening and when. Release managers also became responsible for ensuring the completion of checklists or runbooks of tasks that could improve the success of releases.

Release calendars often slowed down release cycles as every team had to fight for a place on the calendar and wait for available spots to open up. However, they also acted as a control mechanism for managing those teams and system interdependencies.

Release management has become a stabilizing force in software development and delivery because it brings together disparate information to ensure release success by managing scope and coordinating release activities. However, merely providing stability isn't a sustainable state for release managers.

In Part 2 of our release management series, we'll look at how those issues can be addressed and how the role of release management fits into DevOps methodologies.

Go to Part 2: Release Management Through a DevOps Lens