How to use the same ADO pipeline for deploying to dev, staging and production

Question

I'm using ADO to trigger tests and deployments to Google App Engine when I push to Github. Note that I use the same .yaml file to run 2 stages; the first being Test and the second, Deploy. The reason I am not using release pipelines is because the docs suggest that release pipelines are the "classic" way of doing things, and besides, having the deploy code in my yaml means I can version control it (as opposed to using ADO's UI)

I have already set up the 2 stages and they work perfectly fine. However, the deploy right now only works for my dev environment. I wish to use the same stage to deploy to my other environments (staging and production).

Here's what my .yaml looks like:

trigger:
    # list of triggers
stages:
 - stage 'Test'
   pool: 'ubuntu-latest'
   jobs:
     - job: 1
     - job: 2
     - job: 3

 - stage 'Deploy'
   jobs: 
    - job: 'Deploy to dev'

I could potentially do a deploy to staging and production by copying the Deploy to dev job and creating similar jobs for staging and production, but I really want to avoid that because the deployment jobs are pretty huge and I'd hate to maintain 3 separate jobs that all do the same thing, albeit slightly differently. For example, one of the things that the dev jobs does is copy app.yaml files from <repo>/deploy/dev/module/app.yaml. For a deploy to staging, I'd need to have the same job, but use the staging directory: <repo>/deploy/staging/module/app.yaml. This is a direct violation of the DRY (don't repeat yourself) principle.

So I guess my questions are:

Am I doing the right thing by choosing to not use release-pipelines and instead, having the deploy code in my yaml?
Does my azure-pipelines.yaml format look okay?
Should I use variables, set them to either dev, staging, and production in a dependsOn job, then use these variables to replace the directories where I copy the files from? If I do end up using this though, setting the variables will be a challenge.

You could define the deploy job in a template that you reference using a - template: deploy.yml step from all three deployment jobs. This ensures that you only define the actual release steps in one common place. — mm8
Thanks @mm8! That worked great. Since @Lucas added an answer, I will have to accept his, hope that's okay. — a3y3

Lucas Lucas · Accepted Answer · 2020-06-15T19:26:01

Deploying from the yaml is the right approach, you could also leverage the new "Environment" concept to add special gates and approvals before deploying. See the documentation to learn more.

As @mm8 said, using templates here would be a clean way to manage the deployment steps and keep them consistent between environments. You will find more information about it here.

How to use the same ADO pipeline for deploying to dev, staging and production

1 Answers