It appears the initial rollout of Lifecyles defines lifecycles at the project group level and allows each project to pick one of these lifecycles to use for all of its deployments. While this is nice for normal deployments because we can follow a standardized promotion workflow it doesn’t work well for non-standard deployments (a patch, for instance). I believe allowing users to select the lifecycle they want on a per-release basis would make lifecycles much more powerful. For example, I can think of two fairly standard lifecycles I would like to have (and I believe would be pretty standard many places):
Default:
Dev -> Testing -> UAT -> Production
Patch:
Patch Testing -> Production
During a patch to fix a production issue we normally only go through two phases and the servers in our patch testing environment are not the same as those in our standard testing environment. It would be great if I could specify the Patch lifecycle when I created my patch release. Right now I can’t think of a way to setup one lifecycle that would accommodate the above scenario so now I am basically back to having one lifecycle defined that just lets me deploy anywhere (chaos) because the only way for me to achieve the above is to go edit the process definition to choose my Patch lifecycle before creating my release. This of course isn’t optimal as many times I have standard releases being created for feature work in the same day as a patch could be.
Thanks for the feedback. We’ll be adding branching support to a future version of Octopus, and we also plan to add different ‘categories’ of releases. Categories would be things like ‘Full deployment with schema changes’, ‘Minor patch’, ‘Critical production fix’, etc.
Each category can then have its own lifecycle and some steps could be configured to only run under certain categories of releases. When creating a release, you’ll just choose the category.
This sounds like it may solve the issue I’m currently running into. All of our code is initially checked into a development branch, which is then deployed to a dev environment, followed by a test environment. Once those changes are approved, they are merged into a release branch, which is then deployed to QA, followed by Production.
In other words, packages from branch A are only deployed to environments A and B, and packages from branch B are only deployed to environments C and D.
I don’t see a way to support this scenario with the current Lifecycle implementation. I’d also like to use the automatic release creation, so please take that into consideration as well.
Something like being able to define that a package coming from Branch A (by pre-release tag) is automatically associated with Workflow A, and a package coming from Branch B is automatically associated with Workflow B. Workflow A would contain Dev and Test, and B would contain QA and Production.
Just to make sure I didn’t miss a thread update or a completion. Much like Eric’s example, we have CI going on which should never make it past point B (QA), however we then the production release which is tagged and obviously should be allowed to go past QA.
We know the intent before we do the build for this, however as the lifecycle appears to be for the project, which means I don’t think it’s snapshotted as part of the release so even if for CI stuff I would set it to Dev–>QA and then for the production release make the adjustments by picking a different lifecycle and using the additional/adjusted environments.
We’ll be releasing a beta for 3.2 which includes the Channels feature (formerly named “branching”) in the next couple of weeks. Stay tuned to our blog for the reveal.