We are getting to the final stages in preparation for our first production deployment of a web app, but are getting a little confused with the usage of channels and / or lifecycles. And were hoping you could provide some best practices guidance.
Up until now we’ve really had one lifecycle (the default lifecycle) that just deploys to all environments (develop > staging > production soon).
The versioning scheme that we are putting out, for example, is 2.1.0-unstable.32, 2.1.0-rc.53, and potentially a strict 2.1.0.0 version. In the last week, I’ve created two lifecycles: Nightly and Release. The nightly (-unstable) builds go straight to develop. We’re currently in code freeze, so producing -rc (release/2.x.x) builds go to staging for stakeholder testing.
But in creating a production environment in Octopus, I realized I’m not real sure what lifecycle or channel to put it on. Does it go in the Release channel? Or the default lifecycle? Or does it get it’s own entirely new channel and lifecycle?
Summary:
We produce -unstable, -rc and strict 2.x.x.x builds
We have a develop, staging, demo, and production environment
We have a Nightly and Release channel, that both have their own corresponding Lifecycles (which seems a little weird, since it’s 1 to 1)
That is an interesting question. This is one of those where I have to answer your question with a question? What is the difference between a strict 2.x.x.x build an a -rc build? Are they functionally the same? How does a build go from an -rc build to a 2.x.x.x build?
I want to wrap my head around your process a bit, because that will ultimately drive the answer as to what is the “best practice.” I found that term a bit of a misnomer because my best practice might not be the best practice for you 
1 Like
To be honest, the only difference is that it’s built out of master instead of release/2.1.0. I guess you could say that, following Octopus deploys “build once, deploy everywhere” model, technically the rc build should go to production. It’s battle tested and owner approved.
We use GitVersion, so that’s really the only thing that tags a strict “2.1.x.x” build - it’s out of master.
Having your -RC build go to production would be my recommendation if that is the one being tested. It “should” be the same as what is built out of master, but that build comes after a merge. I’m sure you have seen situations where a merge conflict resulted in a broken build. So even though it is probably 99.99% the same as what you tested, that .01% could be just different enough to ruin your day.
In fact with channels you can configure a lifecycle and a version rule to enforce that only packages with -RC go to production.
If that is something you can’t or don’t want to do, my recommendation would be three lifecycles and three channels for your naming conventions.
-unstable = Development only
-rc = Staging only
strict = Staging and Production
This will at least give you two different environments to test your strict version with.
Hope that helps!
Thank you, this was very helpful! That is what we ended up going with - channel versioning restrictions.
