Separate staging and production pipelines

Question

I'd like to have separate pipelines for microservices, and also staging and production. It would look like this:

I'm just starting to setup the azure-pipelines.yaml and have this as the trigger for admin:

trigger:
  branches:
    include:
    - staging
    - production
  paths:
    include:
    - admin/*

resources:
  - repo: self

The issue I'm running into, as you might see right off the bat, is that when I commit to staging it is triggering both of the pipelines.

So my question is: is there a way to have one yaml for both staging and production for this microservice or do I need to have two separate yaml files?

EDIT:

Given these two things, I think what I'm trying to do is unlikely unless I make separate adminStaging.yaml and adminProduction.yaml:

You cannot use variables in triggers, as variables are evaluated at runtime (after the trigger has fired).

If you use templates to author YAML files, then you can only specify triggers in the main YAML file for the pipeline. You cannot specify triggers in the template files.

https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml

Branch-per-environment is an antiquated pattern that doesn't work well with Git or modern thinking around how continuous delivery should be implemented. I'd suggest revisiting your branching strategy and adopting something like GitFlow or GitHubFlow. — Daniel Mann
@DanielMann Thanks for the suggestion. reading up on it now. — cjones
Also, without seeing the rest of your pipeline, I'm not convinced that the reason you're getting the production environment built/deployed is because of your trigger statement. As coded, your example says that a commit on either of those branches triggers the pipeline, not that it triggers both environments. — WaitingForGuacamole

Max Morrow Max Morrow · Accepted Answer · 2021-02-22T21:24:27

I agree with @Daniel Mann, you should move toward adopting a more modern branching strategy. Gitflow or Trunk-based with release branches is typically what I use:

They each have their advantages and disadvantages, but either will cover your use-case. You'd you a non-prod branch (develop or rc/*) and a production branch (master). UAT deployments would be triggered off of the non-prod branch(es) and prod releases would be triggered from master.

However, to address your question regarding if it's possible to deploy to both UAT and Production, while having a trigger pointed to both branches, yes. You're able to set up your YAML pipelines to be able to, but it's a bit inelegant.

Effectively, what you'd want to do is use either a condition or an if statement to selectively run your stages based upon the branch I've included both in the example below:

name: Stackoverflow-Example-Multiple-Triggers
trigger:
    - staging
    - production
stages:
    - ${{ if contains(variables['Build.SourceBranch'], 'refs/heads/staging') }}:
      - stage: StageA
        displayName: "Stage A"
        jobs:
          - job: output_message_job_a
            displayName: "Output Message Job"
            pool:
                vmImage: "ubuntu-latest"
            steps:
                - powershell: echo "Hello World!"
                  displayName: "Output Message"
            condition: contains(variables['Build.SourceBranch'], 'refs/heads/staging')

    - ${{ if contains(variables['Build.SourceBranch'], 'refs/heads/production') }}:
      - stage: StageB
        displayName: "Stage B"
        jobs:
          - job: output_message_job_b
            displayName: "Output Message Job"
            pool:
                vmImage: "ubuntu-latest"
            steps:
                - powershell: echo "Hello World!"
                  displayName: "Output Message"
            condition: contains(variables['Build.SourceBranch'], 'refs/heads/production')

You'll want to note that the behavior of conditions vs if statements differ:

Conditions: Will display the skipped stages within the pipeline, but not run them.
If Statements: Will skip the interpretation of the YAML that doesn't meet the if statement criteria entirely and won't display within your pipeline execution. This means, your pipeline will fail if you attempt to run it on anything other than staging or production branches.

Separate staging and production pipelines

1 Answers