I really wanted to separate build from deploy tasks, so TeamCity does our builds and uploads to the Octopus library - package-1.0.x is for staging/prod, package-0.0.x is for testdrive auto-deployment.
I set a rule that says 'any new package-0.0.x, create release, and deploy on new release' - only for the testdrive-autodeploy channel.
Then we added a number of other package sources to the project process - all with matching version schema (and channel version rules to match).
Unfortunately, the only package in the release that is on the correct 0.0.x version is the one in the ARC trigger. So this means we need to continue our old practice of using TeamCity to trigger deployments.
Not world ending, but all we're missing from Octopus is the ability to specify 'from the list of packages required in my process, use only (version rule), and trigger when a new package-0.0.x shows up.
Chris Trotter
I really wanted to separate build from deploy tasks, so TeamCity does our builds and uploads to the Octopus library - package-1.0.x is for staging/prod, package-0.0.x is for testdrive auto-deployment.
I set a rule that says 'any new package-0.0.x, create release, and deploy on new release' - only for the testdrive-autodeploy channel.
Then we added a number of other package sources to the project process - all with matching version schema (and channel version rules to match).
Unfortunately, the only package in the release that is on the correct 0.0.x version is the one in the ARC trigger. So this means we need to continue our old practice of using TeamCity to trigger deployments.
Not world ending, but all we're missing from Octopus is the ability to specify 'from the list of packages required in my process, use only (version rule), and trigger when a new package-0.0.x shows up.