Azure DevOps Org Patterns for separated teams

Question

Are there any patterns or documents around AzDo Setups where there is a central IaC pipeline and then sub teams deploying application related or platform related resources in an Azure Environment with Private endpoints/Services.

Teams would need to get Infra changes from central pipeline. What are the options to trigger jobs from another repo and how would you secure the service connection to run only in specific projects with specific pipelines only? Teams should only be able to call the infra pipeline to refresh? Is this even possible?

j_folberth · Answer

For the YAML I think you are looking for Templates in a shared repository. This repository could be stored in a seperate project.  Based on what you are saying above I'd recommend a call to the centralized template in a repository gated by those with the appropriate access. (personally, would call a stage template which would call a job template which would call a task template). The template should accept the "project name". This project name should ultimately also be part of a variable template which is also in the central repository and under appropriate permissions.The variable template based on the project will contain the specific information such as the source connection and other pieces. I have a series of blogs that outlines some of the practices: https://techcommunity.microsoft.com/t5/healthcare-and-life-sciences/bg-p/HealthcareAndLifeSciencesBlog/label-name/YAML%20Pipeline%20SeriesHopefully this helps.

j_folberth · Answer

Would need to know more detail to better answer this question. When we say central IaC pipeline are referring to a central repository or a pipeline that deploys an entire subscription(s) resources? Also is this around a module based deployment (Bicep, ARM, Terraform?)

quest198z · Answer

So there is a central team that manages IaC deployments for All Azure resources. Due to our structure in the organization, devs can modify or push code to the resources. They will have their own AzDo Projects. The Central Team pushes the Infra in one project and then once completed, dev teams can go about deploying to the resource. The challenge I have is how can the devs call that Infra pipeline or are there ways to connect to two different pipelines if they are in different AzDo Projects. My question can their be a way to merge the two or share service connections with proper controls in AzDo? In regards to the ARM/Bicep with template specs to version a collection of resources for a product catalog. We are looking at Terraform now because of state or consistency issues, but I do know that deployment stacks for ARM is coming out. In any case, I'm looking for patterns for when an org has this type of structure.

j_folberth · Answer

It still is not clear when referring to "infra in one project'" is this a single repo w/ all the infrastructure or a repo per app infrastructure?

There is a way to chain pipelines together; however, I feel this will cause overhead and run some risk as a good practice is typically have a single multi-stage pipeline that goes to DEV, STG, then PRD as opposed to three separate pipelines with one for each environment.

I THINK what you would be looking at is something like a YAML repository resource block that will copy the source infrastructure from the repository and produce it as an artifact to the development team's pipelines. This will limit their control/ability to update the Infra; however, have a copy associated with their app code pipeline and deployed with it. This will really help if ever needing to rollback and prevent any environment drift.

To achieve this in the developer pipeline the IaC project/repository would be declared as a resource block https://learn.microsoft.com/en-us/azure/devops/pipelines/process/resources?view=azure-devops&tabs=schema#define-a-pipelines-resource

Then will want to publish the IaC to the developer pipeline https://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/pipeline-artifacts?view=azure-devops&tabs=yaml

This will also have the benefit of consolidating pipelines and ensuring the IaC components are deployed via a Service Connection. The developers will still not be able to maintain the IaC; however, have the ability to control deployment of it.

Alternatively, since you are in ARM/Bicep would recommend at least evaluating the use of Bicep Registries https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/private-module-registry?tabs=azure-powershell to centralize your templates for mass consumption.

quest198z · Answer

First off, I would like to say thank you so much for responding and giving some feedback!Let me provide better info. We have an AzDo organization that has many projects for different teams. There is one project that is used to store all the Azure Templates for application deployments and then every team has their own projects to store application code.Due to restrictions by our security team, developers can deploy their apps to the Resource groups they own but the Service Connections used in AzDo have enough RBAC for that RG only. They can deploy app code and do specific things with no issues. When it comes to deploying Azure Infra Services where you can not deploy over the internet, this presents some challenges.Our environment has a hub and spoke model that needs to deploy Infra resources inside of their RG, but then will need to create subnets or private endpoints in another Rg (network resources are separated from the app RG, then deploy DNS records in central location). This is done with a Service Connection that has elevated access at a management-level group.The other development teams can not leak out of their RG like this account. If we used Azure with Public resources, this would be easy to do and stick everything in one YAML.Since we can not do this, we have to privatize all services we consume, which becomes a challenge. So this is why we can not put everything in one repo or YAML. Now there may be other ways like you are saying so I'm intrigued at the moment.Now, if I can even publish a specific artifact that is tied with a set of parameters with that elevated Service Connection, but that they can not edit it, I would love that. This would allow us to get over issues and deploy in unison.Hope this provides more color.Thanks in adv!!!

Forum Discussion

Azure DevOps Org Patterns for separated teams

9 Replies

Resources