In Octopus we take a strong view that deployments should be repeatable. When you prepare to deploy a project using Octopus, you take some time to define your deployment process. In Octopus, this is represented by a set of deployment steps that you define on the Steps tab.
I've noticed a couple of common mistakes that people make when it comes to defining steps. To help, here are two things you can do to reduce the need to have to duplicate your deployment steps.
Tip 1: Use the same roles in all environments
When you create a package or script step, you specify the roles that the step is deployed to:
People sometimes assume that when I select the web-server role above, the step will be run against all machines in that role regardless of the environment I deploy to. That isn't the case. When I deploy to my Development environment, the step will only be run against web-server machines in the Development environment. When I deploy to Production, the step will only be run against machines in the web-server role in the Production environment.
If your role names end with "prod" or "uat" or "dev", it's quite likely that you aren't using roles properly.
There's a theory that when it comes to software, if the user assumes it must work a certain way, and it doesn't, then the software is at fault and not the user. I think that's largely true. In this case I suspect it's because we don't do a good job from a UX point of view of making it clear what will happen during deployment. If you have any suggestions on how we can make this clearer, please leave a comment below.
Tip 2: Use variables to account for differences between environments
When defining a step, many fields allow you to reference variables. You can tell whether a field supports it by looking for the hash button next to a field.
Suppose I need to deploy an Azure cloud service package to two different cloud services in Azure. I could go and create two different steps, and select a different environment for each. A better way, however, is to define variables scoped to each environment.
Then, I can refer to that variable when defining a step:
Hopefully these two tricks will help you to reduce the number of deployment steps you need to define.