Debug, Test and Release build configuration and OctopusDeploy + TeamCity

This is my scenario.
I have various build configuration (Debug, Test and Release) in Visual Studio solution. Now I want to configure somehow TeamCity’s build configuration is a way that OctoPack creates nuget packages for all thee configurations so OctopusDeploycan fetch them.
In OctopusDeploy I have created environments and one project with steps. I want to deploy different WebApp, WebAdminApp and WindowsService to different environments. Test Env gets *Test.nupkg, Production Env gets *Release.nupkg and so on.

Unfortunately there is number of issues:
1.Octopack seem to create only one “build configuration” package set (for example *-Release.nupkg"
2.I don’t know how to configure correctly OctopusDeploy project’s variable

I tried to follow this thread but it does not work

Is there any tutorial explaining how to configure the above scenario?

Hi Pawel,

Thanks for getting in touch. I’m going to write a blog post about this as the answer is pretty long. I’ll let you know when the post is available in the next couple of days.


Hi Paul,

Thank you for clarification that creating such a configuration takes bit longer. Honestly I was little surprised that this topic was touched only barely. This is quite common scenario, at least in projects I was involved in. After spending ~10h in making this working I had to ask for help…

I will wait for your answer on the blog and in the meantime I will make a quick & dirty hack to have some releases deployed :wink:


Any news regarding this, pretty important, blog post ?

I’m also interested in how this can be accomplished, but in our case we are using TFS (vNext) to build.


Sorry for the delay, I’m hoping to get to this this week.


Paul, was the topic of Debug vs. Release binaries ever clarified?

I need the answer for this as well. I’m trying to do the same thing with multiple projects in one solution and can’t seem to do it.

– I just found an answer that will work for me…using multiple configurations in one build process and then adding an environment name to the package id…in the end it looks like ‘’ and etc…


Hi Everyone,

Thanks for being patient. Paul hasn’t been able to publish that blog post as yet. In the meantime I will provide some guide-posts to help you piece it all together.

1. Producing the right packages

You will need to produce one entire set of packages for each environment. In this case you will need to perform multiple rebuilds of your entire solution. Let’s consider one of these builds targeting the Test environment:

msbuild.exe MySolution.sln /t:Rebuild /p:Configuration=Test /p:OctoPackPackageVersion="3.1.5" /p:OctoPackAppendToPackageId=Test

You should use the Configuration, OctoPackPackageVersion and OctoPackAppendToPackageId appropriate for your scenario.

Which should produce the following packages:

  • MyWebApp.Test.3.1.5.nupkg
  • MyWindowsService.Test.3.1.5.nupkg

And you would rinse-repeat this for each rebuild/environment you require.

  • MyWebApp.Production.3.1.5.nupkg
  • MyWindowsService.Production.3.1.5.nupkg

More information about packaging applications can be found here including advanced usage of OctoPack.

You may be wondering why we didn’t use a pre-release tag for the environment? It would have been a misuse of Semantic Versioning to put an environment name in the pre-release section, but more than that, we need to switch packages using variables - and you cannot use variables to control which version of a package is deployed to an environment on-the-fly - the Release controls the package version.

2. Making the packages available to Octopus Deploy

There are a lot of ways you can consume packages from Octopus, pick the one that suits you best! My preference is to push packages to the Octopus Built-In Feed which offers the best retention policies.

You need to push all of the packages for all of your environments so deployments do not fail when deploying a release to each environment. Since we will be using a binding expression for the PackageId in the next step, Octopus cannot provide any validation when creating the Release.

3. Use #{} expressions for your PackageId

Each step that requires a package should use a binding expression instead of referencing a specific package. For example:

PackageId: MyWebApp.#{Octopus.Environment.Name}

And now the package that is actually deployed will be selected using the environment name as part of the Package Id. For example:

  • Deploying to Test: MyWebApp.Test
  • Deploying to Production: MyWebApp.Production

Let me know if that works, or if there’s any gaps that we should fill in, and let’s see if we can publish that blog post.

Hope that helps!