Deploying a release with multiple NuGet Packages to multiple environments via team city to Azure

TeamCity + Octopus Deploy + Azure

We have a Visual Studio Solution which which has multiple projects. Which become Package1 Package2

When we deploy we:

Build the solution.
Run tests etc.
Create Release using OctoPac
Deploy Release using Octopac

In TeamCity under the build step to deploy a release i specifiy 2 environments EnvA EnvB

In Octopus, I have 2 Environments setup EnvA with AzureTarget1 & EnvB with Azure Target2

I have a project with 2 process steps.

Process 1 : Deploy Package1 to EnvA
Process 2: Deploy Package2 to EnvB

But TeamCity gives me this error:

Release '1.0.45' of project 'App' cannot be deployed to environment 'EnvB' because the environment is not in the list of environments that this release can be deployed to. This may be because 
a) the environment does not exist, 
b) the name is misspelled, 
c) you don't have permission to deploy to this environment, or 
d) the environment is not in the list of environments defined by the project group.
[01:03:09][Octopus Deploy] Exit code: -1

a) The env does exist.
b) The name is spelled correctly.
c) I do have permission to deploy. If i don’t specify EnvB in team city, Everything works except there is no deploy to EnvB.
d) I’m not sure this matters since I have not defined any project groups.

Any advice?

Hi!

Thanks for getting in touch. I’ve read over your description a couple of times and unfortunately I don’t have a clear answer for you right now. That being said there’s a couple of things you can try for me and we’ll work through this together.

The error you mentioned comes from Octo.exe which is an open-source project, so you can see the code that raises the error: https://github.com/OctopusDeploy/Octopus-Tools/blob/24b72cea917eaf27bbd8c8eca55e90291c04f096/source/OctopusTools/Commands/DeploymentCommandBase.cs#L84

This is telling you that EnvA is available as a promotion target for this release, but EnvB is not. Promotion targets are defined by Lifecycles, so I wonder if you can take a look over the Lifecycle defined for this project: http://docs.octopusdeploy.com/display/OD/Lifecycles

Also, Octo.exe simply calls the Octopus API which is exactly what the Octopus web UI does, so you should be able to see why the API isn’t returning EnvB as a promotion target by going to the Release and clicking on Deploy to… which will show you the promotion targets (see below)

At least this will help you understand the Lifecycle defined for your project and perhaps how best to structure the project and environments to achieve what you desire.

Hope this helps!
Mike

Ok. So I got it to work, but I don’t truly understand why.

I created a new LifeCycle.
In Phase 1 I added both environments.
I then assigned this LifeCycle to the project. And then it all worked.

Prior i was using the default built in lifecycle which looked to have no Phases, but the docs said that they should work as long as I deployed to them in the order they were listed on the environments page. I’m not sure why order of how they are displayed matters, but apparently it didn’t work.

On Team CIty there is a section where you defined the environments you want to deploy to separated by commas, so in our example it was EnvA , EnvB.

So why did creating a single phase with both environments work?

Hi Mark,

Thanks for getting back to me. I’ll do my best to explain from what you’ve told me about your situation.

The Default Lifecycle supports the most common scenario that Environments are used for: progressively deploying a single Release through, say, Dev to Test to Staging to Production. Given this scenario you wouldn’t normally deploy to Dev and Production at the same time.

In your scenario, your project was using the Default Lifecycle with two environments, EnvA and EnvB and by nature, the Default Lifecycle allows you to promote the release through those environments, first to EnvA and then to EnvB.

If you want to allow a Release to be deployed to both EnvA and EnvB as part of the same deployment, you would define a custom Lifecycle to enable this flow. (Like you did)

Hopefully I’ve done a reasonable job of explaining why you’re seeing this behaviour.

This does however make me want to ask the question: why are you deploying the same release to two Environments at the one time? After reading through your initial question I would suggest structuring your deployment like this:

Environment: "Test"
Azure-WebApp-Target-Test-1 (Environment: “Test”, Role: “App1”)
Azure-WebApp-Target-Test-2 (Environment: “Test”, Role: “App2”)

Environment: "Production"
Azure-WebApp-Target-Prod-1 (Environment: “Production”, Role: “App1”)
Azure-WebApp-Target-Prod-2 (Environment: “Production”, Role: “App2”)

This way you are using the Role to define which Package to deploy to the different Azure Web App instances, and the Environment to more naturally define the purpose for the deployment.

Please get back to me and let me know what you think.

Hope that helps!
Mike

Sweet I didn’t understand that roles could be used like that.

We just deployed and it worked Perfectly!

I’ll go with using the routes, its much nicer to think of Environments as Production/Staging/Dev etc.

Thanks again!

Hi Mark,

Thanks again for getting back and letting me know you’re on the path to success. The good/bad thing is you can leverage Environments/Roles to do all sorts of weird and wonderful things. I tend to stay towards the approach of treating Environments as horizontal “maturity” groups and Roles as vertical “responsibility” groups.

Happy Deployments!
Mike