Let’s consider a scenario where a component needs a two step deployment process: install and then deploy. The install step should bring this into the state “Installed”, while the deploy process should bring the component to the “ready” state. Back-out processes should bring the component status from “ready” to “installed” and uninstall from “installed” to nothing.
There are a few variations to this solution based on exactly how you need things to work with IBM UrbanCode Deploy, but here’s one approach:
First, you need to make sure all of the states you want to track are created as Inventory Statuses on the Settings > Statuses page. Here, I have the default “Active” state, as well as the “Installed” state.
Note that the “Installed” status is not marked as unique. This means that you can have more than one version of a component marked as “Installed” on a resource at the same time. This is useful for modeling deployments where the artifacts for multiple versions can be stored on the agent, but only one version is actually running (with the “Active” status) at the same time. In this case, if I add “Active” status for a version, it will automatically remove the “Active” status for every other version on the same resource, whereas the “Installed” status can exist on more than one version for a resource.
Configure Component Processes
Then, you’ll need to define your component processes. You’ll need one component process for every possible action – installing a version, deploying a version, uninstalling a version, and undeploying a version.
Each process needs to be set up appropriately – here’s my configuration for the “Install” process.
For both Install and Deploy, the Process Type should be “Deployment”, and the Inventory Status should be set to the status you want to apply after running that process. For both Uninstall and Undeploy, the process type is “Uninstall”, and again, the inventory status should be set to the status you want to remove when that process is run on a resource.
Configure Application Processes
This gives you all of the component configuration you’ll need. Now it’s up to what you want the application process to do. You can include both Install and Deploy in the same application process, or you can split them into separate application processes. In my case, I put them in the same process:
On each of those two steps, be sure to pick the appropriate component process as well as the appropriate status in the “Use Versions Without Status” field, as here for the Install APP step:
With that set properly, the inventory system can intelligently apply changes depending on whether the version is already installed/deployed on a target agent. For example, if I select version 1.1 for deployment and 1.1 is already on the resource with “Installed” status, but not “Active”, it will skip the Install APP step but will still run the Deploy APP step.
Likewise, add “Uninstall Component” steps to the application process you’ll run to remove the version from a resource. Again, make sure you pick the appropriate inventory status in the “Remove Versions With Status” field:
When that step runs, it will find any versions on the target resource with the “Active” status and run the Undeploy component process to remove that status. (If multiple versions were on a resource at the same time, this would run for each of them.)
Running the Deployment
If I run my Deploy application process and select version 1.1 for JPetStore-APP, this will be the result:
And if I look at the inventory on the resource used here, I will see both statuses:
After this, if I run only the ‘Undeploy’ component process, it will only remove the Active status, leaving the Installed status on the resource: