Build Validation across different Projects

Question

I am stuck in the following Situation. We got an Azure DevOps Organisation with different Projects. The goal is to store all Pipelines and Releases in the "Operations" Project.

The benefit of this is, to keep the individual teams away from dealing with creating Pipelines or handling Secrets (.netrc, Container Registry, etc.)

However there seems to be no way to trigger a build Validation Pull Request in Project A, that triggers the Pipeline in the Operations Project. Build Validations of certain Branches can only trigger Pipelines inside the Project itself

So in short: PR in Project A should trigger Pipeline in Project "Operations"

Is there a workaround for this or is this feature to be implemented in the near future? This threat looked promising that it might be implemented. But it has been quiet since.

Answer 1

I initially asked if you're using YAML pipelines because I have a similar setup designed for the same purpose, to keep YAML pipelines separate from the codebase.

I've heavily leveraged YAML templates to accomplish this. They're the key to keeping the bulk of the logic out of the source code repos. However, you do still need a very light-weight pipeline within the source code itself.

Here's how I'd recommend setting up your pipelines:

1. Create a "Pipelines" repo within your "Operations" project. Use this repo to store the stages of your pipelines.
2. Within the repos containing the source code of the projects you'll be deploying create a YAML file that will extend from a template within your "Operations/Pipelines" repo. It will look something like this:

---

  name: CI-Example-Root-Pipeline-$(Date:yyyyMMdd-HHmmss)
  resources:
   repositories:
    - repository: Templates
      type: git
      name: Operations/Pipelines
  trigger:
   - master
  extends:
   - template: deploy-web-app-1.yml@Templates
     parameters:
       message: "Hello World"

---

3. Create a template within your "Operations/Pipelines" repo that holds all stages for your app deployment. Here's an example:

---

parameters:
  message: ""
stages:
   - stage: output_message_stage
     displayName: "Output Message Stage"
     jobs:
        - job: output_message_job
          displayName: "Output Message Job"
          pool:
            vmImage: "ubuntu-latest"
          steps:
           - powershell: Write-Host "${{ parameters.message }}

---

With this configuration, you can control all of your pipelines within your Operations/Pipelines repo, outside of the individual projects that will be consuming. You can restrict access to it, so only authorized team members have the capability of creating/modifying pipelines.

Optionally, you can add an environment check that requires certain environments to inherit from your templates, which will stop deployments that have been modified to not use the pipelines you've created:

Microsoft has published a good primer on using YAML templates for security that will elaborate on some of the other strategies you can use as well:

• https://learn.microsoft.com/en-us/azure/devops/pipelines/security/templates?view=azure-devops