Deployment Automation - the power of Snapshots

Deployment Automation - the power of Snapshots

Snapshot1.PNG

One of the most powerful and useful features of Micro Focus Deployment Automation is snapshots. If you are not using snapshots, then you are not really getting the most out of this tool. In this post I will explain what a snapshot is and how to use them effectively. I will also look at some of the more "mysterious" snapshot features. 

snapshot represents the current state of an application in an environment. It is used to specify a combination of component versions that you are going to deploy together. As an example, in the diagram below we have three environments: Integration, UAT and Production. There are a number of different versions of the WEB and DB components in the Integration environment but a snapshot (called "Snapshot 1") was created at a point in time with the WEB 1.0 and DB 1.0 versions.

Snapshot1.PNG

Once a snapshot has been created, rather than having to specify individual component versions for deployment we can now refer to the collection of versions by the snapshot name. When you have two or more components in an application you will find this extremely useful. Using snapshots essentially raises the level of abstraction meaning you can now regard the snapshot as a "Release Candidate". Once a snapshot has been created it can then be promoted through a Deployment Pipeline - UAT and Production in our example

Snapshots are typically created in an "uncontrolled" environment - in this case Integration - where there is no approval process required or gates defined (more on gates later). In such an environment Developers typically have free permission to create new component versions and deploy. They might be executing the deployment themselves or maybe one of the plugins to build tools such as Jenkins or Teamcity is automatically deploying to this environment.

Hopefully this sounds good so far, but there is much more that snapshots do...

Component Versions

When you create a snapshot, you can add the component versions you want in it manually (by clicking on the Add Versions link as shown in the screenshot below) or you can select Copy from Environment. In which case you are prompted for the environment you want to copy the versions from (say Integration) and the versions are filled in automatically for you.

da-snapshot-exxample.png

 

Note that if you have components that use "incremental" versions rather than "full" versions (for example database change sets) you might have multiple versions represented for a single component. You add these versions into a specific order if required. The use of "incremental" or "full" versions is worthy of a post in its own right, see: Deployment Automation - Full and Incremental Versions.

Snapshot Configuration

As well as the component versions, a snapshot includes a configuration that contains the versions of the processes that have been modeled, the properties that these processes use and many other things (such as the version of the approval process defined for each environment!) Have a look at the screenshot below to see the typical contents of a snapshot configuration.

da-snapshot-configuration.png

 

Effectively a snapshot is a true representation of how a deployment was (or could be) carried out at a point in time. This means for example that if the processes continue to evolve (as they should) the process versions will be updated but the versions recorded in the snapshot will not be (unless you want them to of course).

One of the interesting points to note about the screenshot above is that as well as navigating to the version of a process or properties that the snapshot uses (via the Details icon link), there is also an option to Set Version. If you clicked on this option you would be presented with all of the versions of the process or properties as well as an option to Always use latest version:

da-snapshot-set-version.png

 

If there was an error with the deployment that was down to the process modeled then you could select a previous version (or fixed and later version) for the snapshot to use. Selecting Always use latest version means that if a new version of the deployment process is created or properties updated, the snapshot will automatically pick them up.

There are a couple of additional buttons at the bottom of the Configuration page:

da-snapshot-buttons.png

 

Reset All to Latest will effectively update everything with the latest versions that exist. Lock Loose Entries on the other hand is used if you have set Always use latest version anywhere - it will effectively set the version to the latest version at this point in time - meaning if the version is updated it will no longer be the latest that is selected!

Snapshot Status

Each snapshot can have one or more statuses applied to it:

da-snapshot-status.png

 

These statuses typically represent the fact the snapshot has been deployed successful (or not) to an environment and they are used in gates (see below). Statuses can be applied manually (using the screen above) or more likely they are applied automatically as part of the deployment process itself. To apply the statuses automatically you can create a component (or generic) process that looks at the environment name and applies the relevant status using the DA Version plugin or you can use the application process Snapshot plugin.

Gates

Gates allow you to prevent deployments being carried out to an environment if the component versions or snapshot have not yet reached a particular status, e.g. you can't deploy to Production environment unless the UAT environment has been deployed to first. The screenshot below illustrates some example of gates for snapshots:

da=environment-gates.png

 

In this example I have combined version and snapshot statuses in the UAT environment. This allows me to apply the Hot Fix status to component versions and have them deployed irrespective of the status of the snapshot itself.

Snapshot Lock

Snapshots can be locked when they are deployed to a particular environment. Locking snapshots means that nothing can be changed, not their name or contents. You would typically lock a snapshot when it goes into a Pre Production environment - then it is the locked version that is deployed to Production. A locked snapshot in Production should represent an immutable configuration so that you can use it to setup a test or fix environment.

Snapshots rule!

As you can see snapshots have a significant amount of capability and encapsulate a large amount of data - you can even compare snapshots to see differences in component versions or configuration. I hope that you have understood a bit more about you can use them and get more value out of Deployment Automation.

Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Comments
Interesting information about snapshots!
Great blog Kevin! The power of Snapshots and Gates is often unrecognized by SDA customers. This is a great introduction to the topic. It's important to re-iterate that using a snapshot is a great way to get a known configuration from one environment to another. Used in conjunction with virtual / physical / cloud automation this can really simplify the setup and configuration of environments in a deployment pipeline.
Great overview!
Top Contributors
Version history
Revision #:
6 of 6
Last update:
‎2020-01-27 18:26
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.