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...
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
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_folberth
Microsoft
MicrosoftFor 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.
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.