Forum Discussion
Azure DevOps Org Patterns for separated teams
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 wit...
j_folberth
Microsoft
MicrosoftWould 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?)
- 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_folberthIt 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.- We have template specs but again, the issue arises when the full infra deployment happens. We privatize services in azure so the usage of private endpoints and private dns is in play. These things are centralized. In a large organization you are not giving developers access to spin up private networks or create their own private dns zones etc.... The app teams have app registrations for their local resource group deployments but can not leak out. This is why we have an infra and app pipeline.
The first option I'm interested in because if there is a way to write a block of yaml and publish it where it calls a specific template spec with settings in a yaml where they could just ingest and not make any settings that is fine. We would even all them to override the parameters. This would ensure that they can not change or reuse that service connection in deployment without following this process.
So is it possible just in a high level:
You create a yaml file
just taking an example on line
trigger:
- main
name: Deploy Bicep files
variables:
vmImageName: 'ubuntu-latest'
azureServiceConnection: 'elevated-service-connection'** <== they should not be able to change
resourceGroupName: 'rg-projectname-use2-dev'
location: 'eastus2'
templateFile: './main.bicep'
pool:
vmImage: $(vmImageName)
steps:
- task: AzureResourceManagerTemplateDeployment@3
inputs:
deploymentScope: 'Resource Group'
azureResourceManagerConnection: '$(azureServiceConnection)'
action: 'Create Or Update Resource Group'
resourceGroupName: '$(resourceGroupName)'
location: '$(location)'
templateLocation: 'Linked artifact'
csmFile: '$(templateFile)'
overrideParameters: '-storageAccountType Standard_LRS'
deploymentMode: 'Incremental'
deploymentName: 'DeployPipelineTemplate'
developer calls this
The developer just calls this with a package and can just pass a parameters override variable or file to the package
To deploy at scale, we could make pipelines which generate artifacts for groups that take in parameters and pass them in to different organizatin projects for consumption
