SDA - Full and Incremental Versions


When you create a new component in SDA, one of the options you will be presented with is whether to create Full or Incremental versions. For new users it is often not clear what this choice means and what the impact is. In this post I will describe the differences between full and incremental versions, when to choose incremental versions and how to deploy and rollback them.

The choice of whether to create full or incremental versions can be summarized as follows:

  • Use Full versions when the artifacts that you are storing represents a standalone, deployable and installable unit; for example you are deploying WAR, JAR, MSI or EXE files.
  • Use Incremental versions when the artifacts that you are storing represent a "changeset", that builds on other versions; for example you are deploying a database change, message queue script or web content.

The choice might seem minor but it has a big impact on how SDA represents the versions in the Inventory it manages for Applications and Resources. As an example refer to the following diagram:

Here we have an Application with three environments, in each environment a WEB and DB component have been deployed. The WEB component has been setup to manage full versions, whereas the DB setup to manage incremental versions. As you can see there is only one version show for the WEB inventory but the DB has multiple versions. This is often not that clear from the top level Environment Inventory page for the Application as only the "last deployed" version is typically show: 

However, if you drill down into an Environment you will see the complete set of incremental versions that have been deployed - but only the latest full version:


Incremental versions and Snapshots

When you create a snapshot in SDA you can either choose to Add Versions manually or Copy from Environment. If you choose to copy the versions from an Environment, it will include all of the incremental versions that have been deployed to the Environment. This means that you can use the snapshot to recreate or rollback to (see next). Sometimes creating a snapshot from an Environment does not preserve the correct ordering, i.e. 1.0,1.1,1.2 and so on. However if you go to Component Versions for the snapshot, you can drag and drop the versions around to set the correct order.

Rolling back Incremental versions

SDA provides a number of capabilities for rollback; for incremental versions there is a specific option to the Rollback Component step called Remove Undesired Incremental versions. Using this option runs an uninstall/rollback component process for each incremental component version that is not in the snapshot. To make use of this capability you will need a snapshot that contains all of the versions you want to keep. As an example scenario see the following diagram:

In this example we want to remove version 1.3, and rollback to the versions that existed before it was deployed. To do this, create a snapshot that contains all of the versions - except 1.3. Then create a new application process (call it Rollback or something similar) and add the Rollback Component step to it. In this step select the component process to be used for rollback and in Rollback Type select Remove Undesired Incremental Versions. Note that SDA can only serve you up the right files for you and update its Inventory - you still need to decide what to do to rollback using these files - for databases it might be running a specific rollback script for the version being removed.

What if you want to rollback to version 1.1 from 1.3?  In this case, you select a snapshot that contains version 1.0 and 1.1 when you run the application process. The process first removes the 1.3 version, and then removes the 1.2 version. It removes versions in the reverse order in which they were deployed.

Updating Inventory to reflect rollback

If you use the above scenario to carry out a rollback, you will have noticed that the Inventory does not reflect the fact that we rolled back to version 1.3:

It would be much nicer to remove this version from the Inventory to reflect the fact that we are now running at version 1.2. To do this we can manipulate the Inventory ourselves. To do this, the first thing is to edit the Rollback process we have created and set its Inventory Management option to Advanced. Now if we edit our design we can add an additional step for Inventory Update, and in this step we set Action to Removed Desired Inventory, and For Which Versions? to All Not in Snapshot (Rollback):

Now if we executed this Rollback process the 1.3 version will be removed from the Inventory and the 1.2 version will be shown as the latest:

Here we are adding/removing the Active status from the Inventory - we could potentially create a Rollback status as well (which would be applied to 1.3) but I'll leave that as an exercise for you to try!



How To-Best Practice
Comment List
Related Discussions