Multiple Environment Paths by Release

I’m a consultant looking to improve my client’s Dev processes. They currently have a very manual process with a lot of applications and a lot of development activities keeping a “release manager” full time. I’ve recommended Octopus Deploy. They are very firm in wanting to follow a particular testing strategy - and I’m looking for advice on the best way to implement this in Octopus.

They plan on Monthly Scheduled Releases and using a Branch by Release strategy in Git. They then want to have two full Dev-QA Environments in parallel that each would promote ultimately to Stage and Production and then “flip”.

For example, They are currently working on a 0925 Release for Dev01->QA01 and a 1025 Release in Dev02-QA02. When 0925 is ready it will go to stage and then production.

However - on 9/25 -they want to continue with the Dev02 branch work on the 1025 release. They would then create a 1125 Release Branch and deploy that to Dev01 -so the testers working on the 1025 Release don’t need to “change environments”.

Note that here are close to two dozen applications. Some I’m hoping can be consolidated into a single project, but we will have ultimately have many projects.

So there will be 2 Environment paths

DEV01-QA01-Staging-Production
DEV02-QA02-Staging-Production

We are using VSTS for Build. I’m hoping to eliminate duplicate definitions in VSTS and Octopus as much as possible, and minimize manual “changes” on those “flipover” occasions.

Thanks!

Hi,

Thanks for getting in touch and providing a good overview of what you’re after. Let me try to answer your questions and feel free to shoot back follow up questions.

2 environment paths
This can be handled by creating two different lifecycles. You’d have six separate environments (DEV01, DEV02, QA01, QA02, Staging and Production), and two different lifecycles following the environment paths you listed.

From here, you can take advantage of our channels feature (introduced in Octopus 3.2), which allows you to create releases that will follow a different lifecycle. Check out our branching documentation for detailed information on a number of scenarios.

We also have comprehensive documentation and a great walkthrough blog post covering channels in detail. It’s a powerful feature, and I’d recommend looking through it to help plan out your strategy.


We are using VSTS for Build
For VSTS, we’d strongly recommend using our extension that can be downloaded here. This extension is simply a wrapper for Octo.exe that allows you to create releases, and you can select which channel to create the release in. We also have a documentation page on VSTS integration with Octopus.

I’ve linked to a lot of resources, so let me know if you have any further questions. We’ll be happy to help. :slight_smile:

Kind regards,

Kenny

From: Kenneth Bates [mailto:tender2+dc8fc6f2e7@tenderapp.com]
Sent: Tuesday, August 29, 2017 10:55 PM
To: Daniel Sniderman DanielS@magenic.com
Subject: Re: Multiple Environment Paths by Release [Questions #12858]

Thanks. This is what I was figuring from reading the documents – but I wanted to a sanity check.

I’ll definitely have questions going forward

Hi,

That sounds good! Don’t hesitate to reach out anytime if you come across further questions. :slight_smile:

Kind regards,

Kenny