(Octopus Deploy) Define different deployment processes for same application

Question

I would like to define different deployment processes for one application. The idea here is that I have one application, that I'd like to deploy to different environments. It's the same application, but I would like to deploy it on one environment with settings A and number of steps A, and then let's say in a week deploy the same application but with the different settings B and another number of steps to another environment. Both environments have nothing in common and are not in the same lifecycle, but they both need the same application. Is there a way to do this. Right now I see only a way to define another Project (the same) in which I can define a new deployment process. Help appreciated. Thank You.

Answer 1

I am going to make some assumptions about the tooling you have, but please clarify if you do not have this:

• Visual Studio
• A build Server (TFS)
• Octopus Deploy Setup
• Both Environments setup with the octo client/tenticle
• Slow Cheetah installed in VS

So once your basic deployment architecture is set, you can then decide how you wish to promote your code. Are the two environments considered completely seperate with their own releases and also their own code promotion path? If so, you should build them as seperate projects with seperate builds. That way you can have one build setup with Auto deploy enabled to environment 1 while the other can be setup to Auto Deploy to environment 2. The Bigger question of frequency (CI, Scheduled, or Manual) would also play into how many different build definitions you should have. To me I would beuild them as two seperate projects in OD and two seperate builds based on what you wrote enabling flexability for deployment automation and further customization (different steps in one, security, ect.). Hope this helps and GL.

Answer 2

The idea here is that I have one application, that I'd like to deploy to different environments. It's the same application, but I would like to deploy it on one environment with settings A and number of steps A, and then let's say in a week deploy the same application but with the different settings B and another number of steps to another environment.

If settings are all you're changing (like web.config or app.config) then variables are your answer. Use the variables tab to swap/change values based on the environment that's being deployed to. Read more about variables here: http://docs.octopusdeploy.com/display/OD/Variables

Environments really don't need anything in common (other than the server role) - but what's slightly unusual is why you would need different steps in different environments. The best practice or rather the underlying motive of having the same steps across environments is for consistency - if your deployment process is the same through out, whatever is deployed in staging should work in production.

Details like configuration would undoubtedly be different from environment to environment - so I guess the first question is: what is so different between environments that requires you to have steps for one environment and not the other?

There are several ways to do what you're asking in regards to steps:

1. Like you mentioned, adding another project would solve this problem.

2. Variables - again, always use variables when dealing with configuration changes - there's no need to really hand-script or have different steps for every environment

3. If you really need to have different steps for different environments, you can specify which environment a step should be targeted for at the bottom in the "Conditions" section. Simply add the environment that step should only be allowed to run in.

What you're asking for is possible all within the same project - and depending on what's being done, it's just not a good practice to have specific steps for specific environments and without more details, I'm not sure how we can help solve this problem of yours.