Migrating yaml build and classic release pipelines to multi-stage yaml

Question

I'm looking at migrating my old CI/ CD pipelines which are a mixture of the new YAML pipelines for builds and the 'classic' UI-based Releases pipelines into a multi-stage, environment-based YAML file, but I'm struggling to find the docs/ examples that follow along with what we are currently doing.

There are usually three environments: Test, UAT and Production.

They're all AKS based and at the moment the build that creates the docker container(s) will, as part of it's output, store a DeployService.yml file that's used by the release pipeline to update each environment (by modifying the image tag, and some environment variables) prior to running kubectl apply -f DeployService.yml.

Currently I've got several projects that follow this pattern:

╔══════════════════════════╦══════════════════╦══════════════╦══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗
║           Name           ║     Purpose      ║     Type     ║                                                                     Description                                                                      ║
╠══════════════════════════╬══════════════════╬══════════════╬══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╣
║ {project-name}.ci.yml    ║ CI build         ║ YAML-based   ║ Triggered on pull-requests. Builds, run tests, etc. The only output is test results and success/ failure in Azure DevOps.                            ║
║ {project-name}.cd.yml    ║ CD build         ║ YAML-based   ║ Builds the output upon successful PR into master. This is more often than not a docker container.                                                    ║
║ {project-name} - Release ║ Release Pipeline ║ 'Classic' UI ║ Release pipeline, triggered by {project-name}.cd.yml success and deploys into the Test environment. From there it's promotion to UAT and Production. ║
╚══════════════════════════╩══════════════════╩══════════════╩══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝

I'd like to move them all to the newer mult-stage YAML build and release pipeline using a single file.

As it stands, I've created a new yaml file by using the new pipeline template and then copying and pasting bits of my existing CD builds.

At at the moment the new build can:

Do a build that creates and pushes the docker container.
Trigger the release that pushes into the Test environment.

As part of this, the template created a manifests folder in the repo that contains a deployment.yml and a service.yml. It also created an environment which connected to our Test AKS cluster.

So my questions are these:

Given the deployment.yml needs to contain environment specific variables (think ASPNETCORE_ENVIRONMENT), how do I provide those additional environment specific variables per-release environment?
Can I re-create the same promotion-style release pipeline that I had using the Classic UI releases?
Will the CI build fit into this process at all? Or should I leave it in a separate file?
Given there are lots of projects that follow this pattern, and for the most part they all do the same thing but build project specific containers, is there any reusability available between repos?

Levi Lu-MSFT Levi Lu-MSFT · Accepted Answer · 2020-03-12T09:58:58

1,Provide additional environment specific variables for deployment.yml.

You can use Magic Chunks task in your pipeline to replace the variables in yaml files during the build process. You need to install Magic Chunks extension to your organization if it is not installed. Please check here for more information this task. You can also the check this thread for an example.

2, You can create the same promotion-style that in Classic UI.

You can define the dependenies and condtions to control a stage running based upon the status of running a previous stage. For below example.

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

You can also add Approvals and Checks for your stages. Please check document Define approvals and checks

However, Yaml pipeline doesnot support manaully trigger a stage yet. This feature is on the roadmap. Please check this thread.

3, I suggest you leave the CI build in a separate file. If it is in the same yaml file, then all the following CD build and stages will get triggered on pull requests.

4, Templates will let you define reusable content, logic, and parameters. You can put the tasks/jobs that are used by many projects in a template yaml file. Please check here for more information about yaml Template.

Migrating yaml build and classic release pipelines to multi-stage yaml

1 Answers