Azure-pipelines-tasks: Help migrating yaml build and classic release pipelines to multi-stage yaml.

[kieronlanning]

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:

1. 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?
2. Can I re-create the same promotion-style release pipeline that I had using the Classic UI releases?
3. Will the CI build fit into this process at all? Or should I leave it in a separate file?
4. 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?

[TheRealDuckboy]

Also very interested in answers to these questions, facing the same issues.

[haymansfield]

Would also like to express an interest in this question.

[ds-ms]

Closing this stale issue. Feel free to reopen if this still needs to be addressed