1

I'm recreating our very complicated deployment process in Azure DevOps. Currently, our live environment is composed of 4 VMs behind a load balancer.

The strategy I thought about is kind of blue-green deployment, just that I'll be working on half (2) of the VMs each time.
It's not like rolling deployment since there will not be 2 versions that run simultaneously.

As soon as I finish deploying the first half and I make sure it's up and running, I'll connect it and immediately disconnect the other half to deploy the new version to it too.

I can't do blue-green for now by the book (deploying a complete separate set of VMs in the new version) since unfortunately IPs are hard-coded. The live environment will be just fine with 2 VMs only for the deployment time.

My problem is how to configure a release pipeline in Azure DevOps for this kind of solution (I use the GUI version, not YAML)? (these are stages)

DbConversionDev > FirstHalfDev > SecondHalfDev > DbConversionQA > FirstHalfQA > SecondHalfQA > DbConversionProd > FirstHalfProd > SecondHalfProd

Maybe the db conversion stage can be parallel.

It's seems complicated and hard to maintain. Any suggestions? Thanks in advance :)

Idan Levi
  • 388
  • 3
  • 18
  • 1
    Seems similar question at [Blue/Green Deployment using VSTS Release Definitions](https://stackoverflow.com/questions/53418132/blue-green-deployment-using-vsts-release-definitions). Have you tried [the solution for vm](http://work.haufegroup.io/Blue-Green-Deployment-on-Azure/)? – Yang Shen - MSFT Mar 17 '20 at 09:49
  • @YangShen-MSFT thanks for your answer. I saw the question from the first link. It's not the same because as I said, the IP addresses are currently hard coded (for internal communication) and I can't switch to different machines. I'm not interested on how to do the switch technically - I just need a maintainable way to configure the pipeline so I can deploy to 1st half of the VMs, then to the other. – Idan Levi Mar 17 '20 at 13:48

1 Answers1

3

what you could try for example is to create deployment groups, e.g. First Group and Second Group - register your agents/VMs to the groups, and in the release pipeline, create Deployment Group job for the First Group, then add the steps to verify the deployment was successful and up/running, and in the same pipeline create another Deployment Group job for the second Deployment Group. (Note: You can create an agentless job for any manual intervention)

EDIT

Here is the complete solution as a summary of the conversation:

Create one Deployment Group for each Environment (e.g. Dev, QA, Prod) and tag the first half of the Agents/VMs in a Deployment Group as blue and the other half as green.

In the release pipeline, create a Stage for each Environment (e.g. Dev, QA, Prod) and in one Stage create 2 Deployment Group Jobs for the corresponding Deployment Group (Dev Stage -> Dev Deployment Group), each Job with a different Tag: blue and green. This will make sure, that in one job half of your VMs will be affected by the deployment.

For reusability purposes, group your Tasks in Task Groups to reuse them in your Deployment Group Jobs.

Mario Dietner
  • 566
  • 2
  • 9
  • Thanks for your answer. I currently use deployment groups, one for every environment (Dev, QA, Prod). I can run a stage twice for the same deployment groups and tag half of the machines as blue and half as green, then, in the first stage I'll use the "blue" as the required tag and "green" for the second. My problem is if I want to deploy to multiple environments, it seems to me that the release pipeline will contain too many stages and it will be hard to maintain\make changes. – Idan Levi Mar 17 '20 at 22:22
  • 1
    "in the first stage I'll use the "blue" as the required tag and "green" for the second" => you do not need 2 stages one for green and one for blue. You can create 2 Deployment Group Jobs in one Stage, and use different Tags. So you will have only 3 Stages: Dev, QA and Prod, with the corresponding Deployment Groups and tagged agents. If i understood your reply correctly?! – Mario Dietner Mar 17 '20 at 22:56
  • You understood perfectly. While what you suggest is probably more organized, I'm still not sure if it makes it more maintainable. First, I don't see an option to clone a Job, I have about 60 tasks with lots of variables in the job :( Second, If I make a change in one job, lets say add a task, I'll need to add it to the other job too (in fact to all jobs in all stages). I can't figure out how to make it reusable. – Idan Levi Mar 18 '20 at 20:28
  • 1
    You should be able to use Task Groups. Select multiple tasks and right click -> Create task group. Probably you want to categorize it as Deploy. You can reuse the same task group in another Job and edit the Task group under Pipelines -> Task Groups. – Mario Dietner Mar 18 '20 at 20:39
  • I actually use Task Groups a lot in my build pipelines. From all the mess I have here, I didn't think about it! I think that combining this with your previous suggestion to have 2 jobs in the same stage, one for each half (color) will be a fair solution. Would you edit your answer with these 2 suggestions so I can accept the answer and maybe help others? Thank you very much! :) – Idan Levi Mar 18 '20 at 21:03
  • First of all sorry for the necromancy to revive this old conversation. As a follow-up question: How does your pipeline determine which is the currently inactive set of machines that it shall deploy to? And more detail on what I mean: In a blue/green deployment strategy I would expect that the set of deployment targets needs to switch from blue to green or vice-versa every time you (successfully) run the pipeline. So I wonder: How do you store the information which set of machines the pipeline is supposed to work with for the respective next run? And how does your pipeline get this information? – Hauke P. Jan 20 '21 at 11:24
  • 1
    @HaukeP. the concept described here is not a classic B/G deployment - its more a mix of rolling ugrade and B/G. For your purposes i would recomend using 2 release pipelines - one for blue and one for green and trigger the release manually - i am currently not aware of other methods with ADO release pipelines. – Mario Dietner Jan 25 '21 at 13:11
  • Thanks for the response, @MarioDietner. – Hauke P. Jan 25 '21 at 16:43