I AM ABHINAV SABHARWAL Lets talk about Release Management

Releases are risky. Often homegrown scripts, manual steps, and runbook orchestrations contribute to the risks involved with application releases.

Having a controlled release process can strengthen release management by ensuring quality, reducing manual tasks, deploying applications consistently across environments, and more.

Development teams, making the changes to meet customers’ needs, realized that they could not keep up with the increased demand.

Agile solutions allowed developers to make rapid changes. However, organizations were unable to achieve the full benefit of Agile. Legacy deployment processes delayed the release of the applications because they were built for infrequent releases.

RELEASES ARE RISKY

Today’s development teams are positioned around the world, each handling a different part of the application. These teams have their own set of tools and processes for deploying the applications. For global team, different processes, and different tools can create a larger challenge when coordinating and orchestrating the release. When orchestrating a global application release, create a single source of truth that will update in real time. Provide visibility and traceability into who created what and when

ESTABLISH A SINGLE SOURCE OF TRUTH

Manual steps in the deployment process create a number of risks. If the step is not documented correctly, or the step is missed in future environments, it cause a failed deployment and production outages. Manual steps are difficult to track and manage. Automation provides a secure and successful way to complete steps crucial to the deployment of applications. The ideal process will be completely automated.

AUTOMATE PAINFUL & MANUAL STEPS

Avoid relying on developer oral history to understand dependencies. complex deployments may contain components that are dependent on one another. If Component A is dependent on a specific version of Component B, not deploying that version of Component B can cause a release failure. Only promote components that were tested together and known to be compatible. As the application moves through various testing environments, it ensures that the exact versions (bit for bit) are being deployed

MANAGE APPLICATION DEPENDENCIES

Not knowing what is on a machine, or in an environment, is exceptionally risky. This is especially true as you deploy to upper environments. An undocumented component existing in an environment is not likely to be compatible with the components in the upcoming release. Tracking the applications that were deployed to a downed machine is a time-consuming, mission-critical task. Making “what is where” visible ensures that application environments contain the desired component version Proper inventory into a release provides complete visibility into different versions of your application.

MAKE “WHAT IS WHERE” VISIBLE

Certifications and approvals ensure quality. Define quality attributes across the release lifecycle. Making certifications and approvals visible, allows stakeholders know what is required for an application to proceed into the next environment of the lifecycle. Define a quality gate to establish minimum entrance requirements to an environment. A gate is a mechanism that ensures items cannot be deployed into an environment unless they have a gate-specified status.

MAKE CERTIFICATIONS & APPROVALS VISIBLE

DEPLOY CONSISTENTLY ACROSS ENVIRONMENTS When a process differs from build, test, and production environments, the chances of errors increase; Because the production process is not being practiced in earlier environments, steps that are unique to the production environment might be incorrect. Use your test environments to practice the deployment process used in production

Often, an item in an upper environment doesn’t exist in a lower environment;

Avoid having a process per environment. To diminish the variance between environments

Consider building environments through automated provisioning strategies.

MAKE THE RELEASE PLAN EASY TO CONSUME A release plan that can be edited on the fly during a planning meeting, and easily understood, makes it obvious to everyone in the room what the impact of the change is.

A proposed change should be previewed and approved without calling another meeting, saving time and money.

A plan that is too hard to understand, on the other hand, will largely be ignored.

This will result in change management theater, rather than actual assessments and management of risks

ANY QUESTIONS?

You can find me at @username user@mail.me