I want to implement Gitflow with Octopus, I currently have three environments and these are mapped to specific branches
Development - develop branch
Quality - release branch
Production - master branch
So when a commit occurs on develop, release or master it will trigger an Octopus release from AppVeyor
This model works, however, if I use this model, I lose the ability to promote changes to variable sets / process steps throughout my deployment process. This would mean, if I change a step, let’s say adding a step to deploy a nuget package - it will attempt to execute this step within the Production environment if I need to hotfix.
I can kind of mitigate this by scoping specific steps and variables but I was wondering whether there was a better way to do this? I looked at channels but I was unsure how I could support the above model.
Its a great question, we have an article in our documentation that addresses the different kinds of branching models that our customers have the most success with. The git flow approach is an example of Environment per branch
In short, we advocate a strategy of building your binaries once and selecting a different branching strategy than Environment per Branch, but because Octopus only really cares about packages, rather than branches - Octopus is flexible enough to make it work if you really want to.
You can make this work in Octopus, by creating a package for each environment and pushing them to environment-specific feeds, and then binding the NuGet feed selector in your package steps to an environment-scoped variable:
I hope this answers your question, let me know if I can provide you with anymore details!
Would you envisage that I would have to use Octopus to promote through environments?
Do you know how I could support the scenario where I would need to hotfix? As a hotfix using the GitFlow approach means a commit into the master (Production environment) and develop (Development environment). If we used this model you wouldn’t be able to use Octopus to promote releases
If I understand correctly, your call to git flow hotfix finish would result in your build server building packages for the development environment feed, and your production environment feed.
At this point Appveyor would likely kick off two deployments, one targeting development and the other targeting production, in commit order.
So the problem here is that in a typical lifecycle the deployment to production should fail because the life cycle prevents it.
You can relax that rule to make the lifecycle more flexible, by marking phases as optional - but this negates much of the benefit of the lifecycle in the first place.
I think it may also be possible to model gitflow’s inherent lifecycles more closely in Octopus (i.e. a gitflow ‘hotfix’ lifecycle looks like a single phase with two environments - Development & Production) and use Channels to target releases down a particular path.
Channels can have version rules, so if your packages have a certain semver suffix - you can automatically drive the channel selection from that - which might be useful in your scenario.
Sorry that I don’t have a definitive answer, I hope this helps!