Branch support for deploying older app versions
As a enterprise developer, who deploys with 2 version of the application (8.0 for QA and 9.0 for dev) I would like an ability to easily create release for version 8 or version 9, without manually selecting version for each package.
That is it for a brief description. Here is a full set-up:
1) Octopus project consists of 5 packages
2) Each package is being built with TeamCity CI Server twice (from trunk and from branch)
3) For deploying on different environments (dev/QA) I am using same project and environments and server role features.
The problem is, that each time I want to deploy to QA I have to manually pick latest 8.0 build (9.0 is selected by default)
As a solution I can suggest creating version constraints for a environment. This will not allow users to mess and accidentally upgrade env. to other major version and improve UX on a "Create release" screen.
Valera Kolupaev
shared this idea
This shipped in 3.2! We called it Channels: https://octopus.com/blog/octopus-deploy-3.2
4 comments
-
David De Sloovere
commented
Link to the blog post http://octopusdeploy.com/blog/rfc-branching
-
Darrell Tunnell
commented
Could this help you achieve what you want?
-
Eric Hoch
commented
Would it make sense to use NuGet prerelease tags for this? I'm currently creating packages like "1.2.3.4-Dev" for Dev and Test, and "1.2.3.3-Main" for Production. Being able to specify that packages for a particular environment should use prerelease packages, and then to specify which tags are valid for that environment would do much to pre-validate the selection.
-
Piers Williams
commented
What I do is create the release directly from TeamCity, and use the flag that allows you to specify the package versions based on the version number of packages in a folder. If you set the TeamCity publish build up to suck in the artifacts (packages) from the correct other builds, you then get the right versions (in the release) that are relevant for the branch.
Its a shame however there's not an option to fail this if all packages don't exist on disk, since you can get the 'wrong' packages into a release very easily and if you are not monitoring the build output you might be none the wiser.