Release Manifests, Smart Deploys, and Recreating Environments

Release Manifests

A release manifest contains the collection of versioned stuff that is being deployed, configuration settings, and approvals. What, how, where, and who approved it. This is similar to a shipping form listing out the boxes sent, value and contents of the goods, destination, and signatures from sender and receiver. Release manifests are also called deployment manifests or Snapshots.

At execution time, the manifest tells us what to do and ideally how to do it. For instance, we should deploy the database, and two web services, and a mobile front end for our application. The manifest coordinates our deployments so that we no longer have to do it by hand.

Smart Deployments

In a tool like uDeploy the manifest (called Snapshot) describes the full desired state for a target environment. When deployed, only the parts that changed are actually installed. Parts of the system that are already at the right version are left alone. This results in a process that works equally well to make a handful of updates in a frequently changed test environment as it does to update many pieces in production.

Promote what was Tested

A basic idea in most SDLC and Service Transition processes is to test an application and promote what was tested to higher environments and then production. As our software has become more modular, this has become more difficult. We realize that our tests did not execute again “a build”. Rather, they tested a number of inter-related components, configuration and infrastructure. We want to promote that whole collection. This idea is the heart of the term “snapshot”. You want to take a snapshot of what is in the test environment (create a release manifest) and promote that collection forward.

Easier Audit

When the manifest contains the full application, audit is much clearer. The manifest name becomes the version of the whole application, and manifest details which versions of each component to trace back to build and source control. Questions like, “What was in production on May 3rd?” become much easier to answer and responsibility for the deployment and approval is clear. With releases performed at the granularity of a full manifest, deployment requests and approvals can be tracked more succinctly as well.

Recreate Prod

Some of our customers who may be asked to recreate an environment as it was at some point in the past. They can simply re-execute the manifest against a test environment to bring back the application as it was. Increasingly, we are seeing the Snapshot also contain information about infrastructure. The more complete the manifest, the better recreating a scenario can be.

This same approach can be used as part of a disaster recovery scenario. Spin up new images in another data-center or cloud provider, and install the right apps onto them.

For more on deployment automation, you should check out our white-papers Deployment Automation Basics and CI and Build Management Evaluation.  Also, you won't want to miss the DevOps webcast we have coming up.