Deployment Automation - the power of Snapshots
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.
A 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.
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...
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.
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.
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.
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:
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:
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!
Each snapshot can have one or more statuses applied to it:
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 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:
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.
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.
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.