Forum Discussion
Azure DevOps Org Patterns for separated teams
Microsoft
- 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- j_folberthFor 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%20Series
Hopefully this helps.
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!!!