We have been using Octopus for more than 2 years now in an enterprise setting. It has been working really well for automated deployments. We are deploying about 30 artifacts (solutions) to roughly 15 servers per environment. We have a scenario where we will do a full deployment of release and then hotfix it later the week. The hotfix will only have 1 or two of the artifacts/ solutions deployed. Problem is, when promoting from the environment, we are required to do 2 or more deploys to mimic it; one full release and then the hotfix to overwrite. I understand that the hotfix could have all the artifacts as in release via a branch merge, but that would be a new, full deploy of hotfix rather than promoting it; that would not comply with our release policy.
We also want to start moving to a micro service based architecture where we have a similar problem. We want to promote solution x with version 2 of it’s dependencies while solution y, with the same dependencies (but older version) stays put. The increase of artifact and nuget packages makes a full deployment very large, timely and risky.
It would be nice to promote parts of a release (certain packages) rather than the entire thing? Or in a case where I split the entire deployment up into just deploying one package each; I need the functionality to kick off 30 deployments as one unit.
Or do you have a recommendation around this?
Hi Wilken,
Thanks for getting in touch! We would suggest using the Channels feature for what you require. You can set specific package steps to each channel so you could hotfix specific packages (and give them a hotfix Lifecycle) but then have a single channel that is an ‘all packages’ standard release that has all packages included and its own Lifecycle.
Have you had much of a read through of our channels documentation and walk-through?
Let me know if you have any questions.
Vanessa
Hi Vanessa, thanks for your response. This solution should help with managing the versions a bit. Another issue we are facing, however; how can we deploy using an old process, but with new packages. When the deployment process and variables change, octopus creates a snapshot for redeployments. But we would like to assign new packages to a “snapshot” in the redeployment of a hotfix? Can I do that?
Hi Wilken,
You can (sorta). You could take the existing release that has the correct version and snapshot, and edit it to reference your new package/channel.
But this is an interesting overall concept that (amazingly?!) no one has ever brought up before.
I wonder if you have either quite a bit of lag between production releases and dev versions, or just lots and lots of changes to process and code between versions… more than usual?
Vanessa
Hi Vanessa, yes. We have a two month release cycle to production. We need to get it down to at least twice a week, but bureaucracy is holding us back. Our deployment process also changes quite regularly as environments change and octopus becomes more powerful.
Would I edit this release via the front end or in the db?
HI Wilken,
Through the UI. All of those fields are editable via the UI, which is much much much safer and doesn’t break our support terms! 
Vanessa
Okay I do this by clicking “edit this release” and assigning new packages? This will keep the snapshot of the process and variables?
Yeah it will only change the package version part of the snapshot. You should be able to tell right away based on being able to view the snapshot variables. Maybe take a screenshot of before. It is a little hacky as a workaround, but all we could offer at this point.
If you wanted something more robust we could possibly help you write a script to copy a snapshot into a new release, but that might take a little while. It would be nicer for you for trace-ability reasons though.
