Deploy Package - Step 2

Hi Team,

I have created a release and created step 1 to deploy to UAT with custominstallation directory with Runs On target in roles = “UAT”.
Now I want to deploy this same release to another environment - Staging.
I tried to create Step2 with configuration changes but there is one additional step in this as below which is a concern for me. Please find attached.
In this step 2, it has a trigger and there is no way to not have the trigger. I don’t need it as I want my team to do testing first on UAT and once it is succeeded, I want to execute this step.

Also, furthermore, I have different customisntallation directory for all environments and different post deployment script too. Hence, I have to create different steps for each environment.

Am I doing it correctly or is there any work around to it?

Hi Bhumika,

Thanks for getting in touch! I’m not entirely sure I understand your problem, but I can suggest an idea for a similar process that works with Octopus and its features.

By the looks of it, you need to configure your project to use some scoping in both the steps and the variables.
If each environment is to use the same package, then you will only need a single package step and to take advantage of our variable scoping feature.

In this example I’m going to use my own Development + Staging environments in place of your UAT + Staging environments.
The first thing I would do is create my package step, name it, configure how you need and set the custom installation directory to something like #{CustomInstallationDirectory}. Assuming that you want this package step to run on every environment in the Lifecycle this is all you need to do here.

The next step is to configure your variables to provide your custom installation directory based on what environment the deployment is run in. If you refer to Screenshot1, you will see I have created two #{CustomInstallationDirectory} variables with different values, I then scope each one to its respective value. I want Development to be installed to C:\Development and Staging to be installed to C:\Staging, so I have scoped them respectively.

The next stage is to create a Manual Intervention step. As Octopus automatically runs each step after another, the manual intervention is a step that will halt the deployment until an authorized Octopus user manually approves it. This will be used to give you the time to run your tests in UAT before the next step is run. Because of this you do not need to worry about the triggers/run conditions for each step.

The next step will be a script step. You can use this script step to run any additional scripts or commands that you would like to. Octopus allows you to place scoped variables inside the script, just as they have been placed in the Custom Installation Directory. This will let you customize how the script is run based on the environment it is running in.

The end result should look something like Screenshot 2 on the process screen and should play out like this.

1: Package is deployed to the Development environment into the #{CustomInstallationDirectory} variable which as we are deploying to Development the scoping will evaluate it to be C:\Development
2: Once the deployment of the package is finished, the deployment will pause until the manual intervention step is actioned.
3: Once actioned your next step, the script step will run, finishing your deployment.

For information on how we do variable scoping in Octopus, we have some fantastic documentation:
http://docs.octopus.com/display/OD/Scoping+variables
Also for some more information on the Manual Intervention step you can read the following documentation page:
http://docs.octopus.com/display/OD/Manual+intervention+and+approvals

If these features don’t match what you are trying to achieve, then could you please explain your workflow in a bit more detail so I can suggest how it can best be adapted to Octopus.

Looking forward to hearing from you.

Best regards,
Daniel