Different process per environment

I have a project that can be deployed to three environments (Internal, Testing, and Production). The internal environment has a local machine running IIS server. Testing and Production environments are deployed to Windows Azure websites.

My understanding is that a project would have a deployment process which should be independent of the environment. But this is not the case here. When deploying to the Internal environment I want to use a step to deploy a nuget package with an IIS configuration. And when deploying to the other environments I want to use a WebDeploy step. How can this be done? I would like to avoid defining multiple steps in a process and manually including/excluding steps during deployment.

Today I use WebDeploy the same way to deploy to an IIS server or to Azure. Can WebDeploy be used the same way from OctopusDeploy?

Hi Ali,

Thanks for getting in touch! You can use Web Deploy from Octopus if you use a custom step template, but this is something we’ll be improving dramatically in Octopus 3.0.

You can also set up multiple steps, and then under the Conditions at the bottom of each step, select which environments it applies to. This way you can execute certain steps only for certain environments, without having to remember to select them before every deployment.

Hope that helps!


Hi Paul,

Thanks for the response. I modified the template for Web Deploy such that it can be used for both IIS deployments and Azure website deployments. This way we have a consistent deployment process. Also added support for sub-applications under Windows Azure and IIS. Seems to work well.

Now I am looking at a way to replace the endpoint addresses in Web.config, such that they are different per environment. I would like to avoid variable substitution for now as we still haven’t fully switched to OctopusDeploy yet. What is the best way to do that?

Hi Ali,

If they are standard appSettings, you can rely on Tentacle to replace them. Alternatively you can use web.config transformation files (e.g., Web.Production.config, Web.Testing.config) to replace the values that way. This page has more details on both approaches:

For anything else, you might need to use PowerShell to manually modify the configuration file. PowerShell makes it pretty easy to work with XML, and Octopus makes it easy to call PowerShell during the deployment (you’ll need to do this in the PreDeploy.ps1 script):

Hope this helps,