Before proceeding, let’s pause to discuss the use cases for each lifecycle
Sprint Lifecycle: to be used during a sprint (or while work is being done for a release). Developer does a PR from a feature branch, it gets approved, and the build server deploys to Development. The majority of the time, the deployments only go to development.
Test to Prod Lifecycle: to be used after a sprint when QA is verifying the code. A release branch is created. The build server sees that and deploys right to Test. Ideally the final build from this branch is pushed through all environments to Production.
UAT to Prod Lifecycle: to be used when a release is held up in UAT. The build server will need a bit of smarts to see this release should go to UAT first and not to Test. If a release is held up in UAT it will need a path to production once all concerns are addressed.
Hotfix Lifecycle: to be used when a production bug is found. When the code is checked in for the hotfix it should be deployed directly to staging to be verified prior to production.
Now that we have our lifecycles, we will need to create channels for each project following this branching strategy.
As an extra layer of protection, each channel will have version rules. Default is using the sprint lifecycle, and it has the latest and greatest code, so releases from the 2020.3.x release is allowed. QA only allows releases in the 2020.2.x releases. UAT only allows releases in 2020.1.x. Meanwhile production has 2019.12.x releases.
The version rules aren’t required. They are there to help prevent code from being deployed via the wrong channel. Having them does add a bit of complexity as you will have to update the version rules after each release branch is created.
The question now becomes, how does a build server know which channel select when creating the release? That will depend entirely on your business rules. What I would recommend is using the Octopus API to check the last release number for each environment. Here is an example on how to do that. Once you know the release number per environment you can infer which channel you need to deploy to.
We use the GitFlow branching strategy and I’ve been thinking about simplifying our release projects with channels, however I am worried that for a hotfix there exists a possibly for the release process to have been changed, for changes made in development, that would break a hotfix e.g. command line arguments for a process get completely changed.
Is this an issue and are there any suggestions on how to best handle it? It’s not the kind of scenario that would happen often, but when trying to release a hotfix I wouldn’t want it to be held up while having to work back through some release process changes.
An approach I came up with to avoid the issue would be to first clone any steps that need editing and then have the edited step only run for the development environment and the unedited step run for the staging and production environments.
Hmmmm, that is an interesting question. It does come up from time to time. If it is just new steps, I’d say scope the steps to run on the specific channels. For example, you add a new step for what is in dev, then scope that step to the dev channel. When it is time to promote then scope that step to the next channel and so on. If you’re not making a lot of changes, hopefully that isn’t a terrible experience.
For variables or step changes, I’d clone the step or variable. Scope the old variable/step to the release channel, and the new variable/step to all the other channels.
As I type this, this isn’t a great experience, it is something I hope we can solve in upcoming releases.