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.nupkgMyWindowsService.Test.3.1.5.nupkg
And you would rinse-repeat this for each rebuild/environment you require.
MyWebApp.Production.3.1.5.nupkgMyWindowsService.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!
Mike
