-
Notifications
You must be signed in to change notification settings - Fork 512
PipelinesOverview
This document provides high-level guidance for deploying the ALZ modules with pipelines and provides sample code for GitHub Actions and Azure DevOps Pipelines. The sample code leverages the orchestration templates, deployment sequence, and prerequisites described in the DeploymentFlow document. In addition to these prerequisites, a GitHub or Azure DevOps account will be needed to run the pipelines.
A pipeline is the repeatable process defined in a configuration file that you use to test and deploy your code. A pipeline includes all the steps you want to execute and in what order. You define your pipeline in a YAML file. A YAML file is a structured text file, similar to how Bicep is a structured text file. You can create and edit YAML files by using any text editor. Because a pipeline YAML file is a code file, the file is stored with your Bicep code in your Git repository. You use Git features to collaborate on your pipeline definition. You can manage different versions of your pipeline file by using commits and branches.
These ALZ sample pipelines sequentially deploy the nine modules detailed in the DeploymentFlow document in a single pipeline job. The pipelines have been configured with manual triggers for learning and experimentation.
flowchart TD
A[Pipeline Job] --> B(Deploy Management Groups);
B --> C(Deploy Custom Policy Definition)
C --> D(Deploy Custom Role Definitions);
D --> E(Deploy Logging Resource Group);
E --> F(Deploy Logging);
F --> G(Deploy Hub Networking Resource Group);
G --> H(Deploy Hub Network);
H --> I(Deploy Role Assignment);
I --> J(Deploy Subscription Placement);
J --> K(Deploy Default Policy Assignments);
K --> L(Deploy Spoke Networking Resource Group);
L --> M(Deploy Spoke Network);
The sample code provides a simple example of a deployment pipeline. In production environments it will likely be necessary to use more advanced pipelines to meet additional requirements. Often different teams are responsible for the various ALZ components and may need to manage their deployments separately to meet their particular requirements.
The sample code uses manually triggered pipelines for learning purposes. For GitHub Actions we use on: [workflow_dispatch]
event for a manually triggered workflow. For Azure DevOps we use trigger: none
for a manually triggered pipeline run.
Typically teams will want to take a more automated approach to running workflows based upon events that occur in the repository, such as a pull request to the main branch. Normally protected by a branch policies to enforce all changes to a protected branch (e.g. main
) must be made via a PR.
For an example of an automated workflow, please review the bicep-build-to-validate.yml file in the workflows directory of this repo.
For many scenarios, it may also make sense to take a more modular approach to ALZ deployment. While a single pipeline is good for learning purposes, separate workflows aligned to ALZ components and the teams that manage them may be required for some organizations.
If you discover any documentation bugs or would like to request new content, please raise them as an issue on the repo.
Contributions to this wiki are done through the main repo under docs/wiki.
- Wiki Home
- Deployment Flow
- Consumer Guide
- How Does ALZ-Bicep Implement Azure Policies?
- How Does ALZ-Bicep Implement resilient deployments across availability zones?
- Contributing
- Telemetry Tracking Using Customer Usage Attribution (PID)
- Azure Container Registry Deployment - Private Bicep Registry
- Sample Pipelines
- Code tours