Best Practice for Development of Releases Concurrently

We currently use a release branching strategy. At any given time, we might have version 1.0 deployed to our production servers, version 2.0 deployed to our UAT servers, version 3.0 deployed to our QA servers, and version 4.0 deployed to our Dev Servers.

With this in mind, what should we do when we run in to an item which needs to be remediated in UAT?

Should we fix the issue, compile nuget packages, deploy to dev, then to qa, then back to UAT? If so, this will disrupt efforts underway on our Dev and QA environments.

Or should we create a channel which allows us to deploy directly to UAT, bypassing QA? If so, how can we ensure the UAT items have not destabilized our QA effort?

Or should we conduct deploy directly to UAT and conduct QA again on the UAT server? This seems kludgy.

Hi Christopher,

Thanks for getting in touch! Generally, while sticking with general CD best practices, our suggestions are always to consider the strategies that are the easiest for you to manage and best match what you currently do.
Octopus can do what you are doing now, however before I tell you how, I would like to understand it more.

Specifically I would like to know how promotion works. Is 4.0 in dev, but will be merged into QA at some point? How to hotfixes currently work? Do you use SemVer or any specific versioning methods and rules?
How does your code get from Dev to Prod?

Let me know!
Vanessa

Edit, sorry, duplicate post

Thank you Vanessa, we are not using semantic versioning. We are using
release branching. We branch for each release, and each branch/release is
given a major revision number. So, when branch/version 4.0 is ready for QA,
we deploy branch 4.0 to the QA environment. With respect to merging, any
issues found and remediated in QA for example, get merged back to main, and
picked up by each branch.

We have been using TeamCity, and have recently added Octopus. But my
question is not how Octopus can be used for any given practice. My question
is what is considered a best practice.

If we set up a lifecycle Dev > Qa > Uat > Production, how do we avoid
destabilizing our QA effort each time we wish to deploy a UAT remediation?

Or is it best practice to use a wide open lifecycle, and conduct QA on our
UAT server?

I thought I would contribute a bit and am going to follow this topic. we are running into a similar issue at my organization. Thanks for posting this Christopher and I’ll be interested in seeing what is recommended.

In my organization, we use release branches also. When a release branch is created, we use a special lifecycle that is changed only for that deployment then changed back to reinforce the deployment process and not interrupt development. If the project is slow enough to the extent that it’s not earth shattering that the environment is updated, we send it up through all environments.

Hi Christopher (and @aworrell),

Sorry for the delay in getting back to you on this. Octopus itself (and I guess us) doesn’t really have a best practice, but we have ways to deal with whatever the best process for your team ends up being.

Having a chat to some of the devs on the team here who were in a past life consultants I believe we understand the issues you might be facing (if not the whys), and what process you will need to build.

Really there seem to be two main options, both valid. One is if what you are deploying is available to be installed multiple times on the same end point then you can make use of channels and variables scopes to those channels. this will allow the same Lifecycle but not overwrite the deployment on any of the environments. (IE have variables for names, directory paths, services all scoped to the channel that is deploying and each release branch will happily live in its own little corner and allow its own pipeline for deployment).
If it isn’t possible or seems a bit hard to manage (and chance to be error prone) then we would suggest a different UAT environment for each branch and a Lifecycle for each where they have the 4 phases but have their own individual environments to never be aware or overwrite any possible part of the deployments. This will probably require the least amount of management of variables, but means you need some extra machines or VMS. It does also mean for one branch you can keep Production out of the pipeline.

Octopus will work for either of these methods, and it will work well. It will come down to your own team flow, processes, management and architecture.

As for which one is the best practice, I don’t know if we have an opinion on that specifically, but Octopus will work beautifully with either that you decide to use.

I can give specifics on either with suggestions or examples if you feel one is more suited to your needs.

Vanessa