A fairly common pattern when deploying incremental changes is to do some sort of setup, then apply a series of incremental changes, and finally do some sort of wrap-up work. A classic example might be when deploying changes to a database. First you may want to run a backup processes, the apply your series of incremental changes, then perform validation. For a single component, the flow might look something like this:
IBM UrbanCode Deploy is model driven and makes some optimizations for incremental deployments. So when you deploy a collection of versions to an environment, Deploy calculates the difference between the new desired state and what has already been installed on the targets. For incremental versions, the install will run for each version. That’s what we want in the middle step, but not in the Pre-run and Cleanup. So we need those steps to run at most once. If the component isn’t changed, they shouldn’t run at all.
While there are a couple of approaches to setting this up that might appear plausible, most will not have the correct behavior in the end. Here’s what works.
1. Create pre-deploy, deploy, post-deploy jobs in the component.
All three jobs are configured on the component itself. The deployment job is configured as a normal install process. The pre/post processes are set to run as “Operational (no version)”. This will ensure that they are available to be run only once, and not run with each version.
2. Create your Application Process
Your application process will be defined as shown in the first image above. The trick, is bringing the Operational jobs (pre & post) into the flow correctly. At or near the bottom of the automation palette, you should find a folder named the same thing as your component. Open that to reveal only the Operational jobs that this component exposes. Bring the processes in from here, rather than using the “Install Component” or “Run process…” widgets.
At this point, the process will be setup to run the jobs only once. However, we still want to ensure that they only run when our component changes. Getting back to our example, we likely would not want to go through a lengthy database backup cycle if a given deployment wasn’t impacting the database. To do this, check the “Run If Component(s) Change” button in the process’s configuration. Then add in the component in question.
Note: Why would you want to have it run only if some other component changed? Perhaps this is a test component and process, and you want to run the tests only if the business logic (a different component) changed.