You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 30, 2025. It is now read-only.
These pipelines need to be run in the order specified. For example, the `Policy` pipeline is dependent on resources deployed by the `Platform Logging` pipeline. Think of it as a layered approach; once the layer is deployed, it only requires re-running if some configuration at that layer changes.
25
27
26
-
In the default implementation, the `Management Groups`, `Platform Logging`, `Policy`, and `Roles` pipelines are run automatically (trigger) whenever a related code change is detected on the `main` branch. The `Networking` and `Subscription` pipelines do not run automatically (no trigger). This behavior can be changed by modifying the corresponding YAML pipeline definition files.
28
+
There are two distinct `Networking` pipelines, each deploys the hub side of a hub & spoke network topology. The `Networking (NVA)` option is intended for environments with a Network Virtual Appliance, and the `Networking (Azure Firewall)` option is intended for environments using Azure Firewall.
29
+
30
+
In the default implementation, the `Management Groups`, `Platform Logging`, `Policy`, and `Roles` pipelines are run automatically (trigger) whenever a related code change is detected on the `main` branch. The `Networking` and `Subscriptions` pipelines do not run automatically (no trigger). This behavior can be changed by modifying the corresponding YAML pipeline definition files.
27
31
28
32
In the default implementation, the `Roles` and `Platform Logging` pipelines are run automatically after a successful run of the `Management Groups` pipeline, and the `Policy` pipeline is run automatically after a successful run of the `Platform Logging` pipeline. Again, this behavior can be changed by modifying the corresponding YAML pipeline definition files.
Copy file name to clipboardExpand all lines: docs/archetypes/authoring-guide.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -116,12 +116,12 @@ Each archetype is intended to be self-contained and provides all deployment temp
116
116
117
117
6. Create a JSON Schema definition for the archetype. Consider using a tool such as [JSON to Jsonschema](https://jsonformatter.org/json-to-jsonschema) to generate the initial schema definition that you customize. For all common features, you must reference the existing definitions for the types. See example: [schemas/latest/landingzones/lz-generic-subscription.json](../../schemas/latest/landingzones/lz-generic-subscription.json)
118
118
119
-
7. Verify archetype deployment through `subscription-ci` Azure DevOps Pipeline. More information on the pipeline can be found in [Azure DevOps Onboarding Guide](../onboarding/ado.md#step-8--configure-subscription-archetypes).
119
+
7. Verify archetype deployment through `subscriptions-ci` Azure DevOps Pipeline. More information on the pipeline can be found in [Azure DevOps Onboarding Guide](../onboarding/ado.md#step-8--configure-subscription-archetypes).
120
120
121
121
- Create a subscription JSON Parameters file per [deployment instructions](#deployment-instructions).
122
122
- Run the pipeline by providing the subscription guid
123
123
124
-
`subscription-ci` pipeline will automatically identify the archetype, the subscription and region based on the file name. The JSON Schema is located by the archetype name and used for pre-deployment verification.
124
+
`subscriptions-ci` pipeline will automatically identify the archetype, the subscription and region based on the file name. The JSON Schema is located by the archetype name and used for pre-deployment verification.
125
125
126
126
Once verifications are complete, the pipeline will move the subscription to the target management group (based on the folder structure) and execute `main.bicep`.
127
127
@@ -175,7 +175,7 @@ An archetype can deploy & configure any number of Azure services. For consisten
- **Resource Tags** - configures tags on resource groups
177
177
178
-
> **Log Analytics Workspace integration**: `main.bicep` must accept an input parameter named `logAnalyticsWorkspaceResourceId`. This parameter is automatically set by `subscription-ci` Pipeline based on the environment configuration. This parameter is used to link Microsoft Defender for Cloud to Log Analytics Workspace.
178
+
> **Log Analytics Workspace integration**: `main.bicep` must accept an input parameter named `logAnalyticsWorkspaceResourceId`. This parameter is automatically set by `subscriptions-ci` Pipeline based on the environment configuration. This parameter is used to link Microsoft Defender for Cloud to Log Analytics Workspace.
179
179
180
180
Input parameters for common features are:
181
181
@@ -276,7 +276,7 @@ As a result, we could either
276
276
277
277
- have Azure deploy the archetype and fail on invalid inputs. An administrator would have to deploy multiple times to fix all errors; or
278
278
279
-
- attempt to detect invalid inputs as a pre-check in our `subscription-ci` pipeline.
279
+
- attempt to detect invalid inputs as a pre-check in our `subscriptions-ci` pipeline.
280
280
281
281
We chose to check the input parameters prior to deployment to identify misconfigurations faster. Validations are performed using JSON Schema definitions. These definitions are located in [schemas/latest/landingzones](../../schemas/latest/landingzones) folder.
282
282
@@ -341,7 +341,7 @@ These parameter files are located in [config/subscription](../../config/subscrip
341
341
342
342
Immediate subfolder defines the environment which is based on Azure DevOps Organization (i.e. `CanadaESLZ`) & Git branch name (i.e. `main`), for example the subfolder will be called `CanadaESLZ-main`. You can have many environments based on Git branch names such as `CanadaESLZ-feature-1`, `CanadaESLZ-dev`, etc.
343
343
344
-
ARM parameter files are used by `subscription-ci` Azure DevOps Pipeline when configuring subscriptions with Azure resources. The pipeline will detect environment, management group, subscription, deployment location and deployment parameters using the folder hierarchy, file name and file content.
344
+
ARM parameter files are used by `subscriptions-ci` Azure DevOps Pipeline when configuring subscriptions with Azure resources. The pipeline will detect environment, management group, subscription, deployment location and deployment parameters using the folder hierarchy, file name and file content.
345
345
346
346
For example when the file path is:
347
347
@@ -395,7 +395,7 @@ There are two approaches for achieving uniquness:
395
395
396
396
In this approach, you must ensure all management group ids are unique yourself.
397
397
398
-
The `subscription-ci` management group detection logic is built to accommodate both scenarios.
398
+
The `subscriptions-ci` management group detection logic is built to accommodate both scenarios.
399
399
400
400
**To support approach #1:**
401
401
@@ -408,7 +408,7 @@ The `subscription-ci` management group detection logic is built to accommodate b
408
408
- DevTest
409
409
```
410
410
411
-
- `subscription-ci` will then take the folder structure and concatenate it to create the management group id. In this example `DevTest` management group id will be `pubsecLandingZonesDevTest`.
411
+
- `subscriptions-ci` will then take the folder structure and concatenate it to create the management group id. In this example `DevTest` management group id will be `pubsecLandingZonesDevTest`.
412
412
413
413
**To support approach #2:**
414
414
@@ -421,4 +421,4 @@ The `subscription-ci` management group detection logic is built to accommodate b
421
421
- DevTest
422
422
```
423
423
424
-
- `subscription-ci` will then take the folder name as the structure (since there aren't any sub folders). In this example `DevTest` management group id will be `DevTest`.
424
+
- `subscriptions-ci` will then take the folder name as the structure (since there aren't any sub folders). In this example `DevTest` management group id will be `DevTest`.
| Subscriptions | subscription.yml | subscription-ci | Configures a new subscription based on the archetype defined in the configuration file name. | spn-azure-platform-ops | None |
559
+
| Subscriptions | subscriptions.yml | subscriptions-ci | Configures a new subscription based on the archetype defined in the configuration file name. | spn-azure-platform-ops | None |
560
560
| Pull Request Validation | pull-request-check.yml | pull-request-validation-ci | Checks for breaking changes to Bicep templates & parameter schemas prior to merging the change to main branch. This pipeline must be configured as a check for the `main` branch. | spn-azure-platform-ops | None |
Copy file name to clipboardExpand all lines: docs/onboarding/azure-devops-pipelines.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1500,7 +1500,7 @@ In order to configure audit stream for Azure Monitor, identify the following inf
1500
1500
5. Select Existing Azure Pipeline YAML file
1501
1501
6. Identify the pipeline in `.pipelines/subscriptions.yml`.
1502
1502
7. Save the pipeline (don't run it yet)
1503
-
8. Rename the pipeline to `subscription-ci`
1503
+
8. Rename the pipeline to `subscriptions-ci`
1504
1504
1505
1505
2. Create a subscription configuration file (JSON)
1506
1506
@@ -1525,9 +1525,9 @@ In order to configure audit stream for Azure Monitor, identify the following inf
1525
1525
3. Run the subscription pipeline
1526
1526
1527
1527
1. In Azure DevOps, go to Pipelines
1528
-
2. Select the `subscription-ci` pipeline and run it.
1528
+
2. Select the `subscriptions-ci` pipeline and run it.
1529
1529
1530
-
> The `subscription-ci` pipeline YAML is configured, by default, to **not** run automatically; you can change this if desired.
1530
+
> The `subscriptions-ci` pipeline YAML is configured, by default, to **not** run automatically; you can change this if desired.
1531
1531
1532
1532
3. In the Run Pipelines dialog window, enter the first 4 digits of your new subscription configuration file name (4 is usually enough of the GUID to uniquely identify the subscription) between the square brackets in the `subscriptions` parameter field. For example: `[802e]`.
Copy file name to clipboardExpand all lines: docs/onboarding/azure-devops-scripts.md
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -227,7 +227,6 @@ Next, edit the newly created file, using the guidance in the following table.
227
227
| DEVOPS_SE_NAME | Azure DevOps service endpoint name. | spn-azure-platform-ops
228
228
| DEVOPS_SE_TEMPLATE | File name for the generated Azure DevOps service endpoint template JSON file. | service-endpoint.AzDevOpsOrg.json
229
229
| DEVOPS_VARIABLES_GROUP_NAME | Azure DevOps variable group name. Leave this set to `firewall-secrets` as the YAML pipeline for networking is hard-coded to use this value. | firewall-secrets
230
-
| DEVOPS_VARIABLES_VALUES | Specify values for the NVA firewall username and password in format `key=value key=value`. Replace `YourUsername` and `YourPassword` in the example with your values. DO NOT commit changes that include username and password plaintext values to your repository. | var-hubnetwork-nva-fwUsername=YourUserName var-hubnetwork-nva-fwPassword=YourPassword
231
230
| DEVOPS_VARIABLES_ARE_SECRET | Indicates whether variables in the variable group are marked as secret. Possible values are `true` or `false`. Recommend using `true` unless you plan to reconfigure your variable group to use another secure source such as KeyVault. | true
232
231
| DEVOPS_OUTPUT_DIR | Name of temporary folder for generated files. | .\output
233
232
@@ -261,7 +260,7 @@ Run the `create-pipelines.bat` script to create the landing zone pipelines:
261
260
- platform-connectivity-hub-nva-ci
262
261
- platform-connectivity-hub-azfw-ci
263
262
- platform-connectivity-hub-azfw-policy-ci
264
-
-subscription-ci
263
+
-subscriptions-ci
265
264
266
265
If you would rather perform these steps manually, detailed guidance is available in the following sections of the [Azure DevOps Pipelines Onboarding Guide](./azure-devops-pipelines.md):
267
266
@@ -296,7 +295,7 @@ Detailed guidance on these configuration requirements is available in the [Azure
296
295
297
296
### Run pipelines
298
297
299
-
Run the `run-pipelines.bat` script to interactively run individual landing zone pipelines. Note that at present time the `subscription-ci` pipeline is not included in the list of runnable pipelines as the script requires additional work to enable that capability.
298
+
Run the `run-pipelines.bat` script to interactively run individual landing zone pipelines. Note that at present time the `subscriptions-ci` pipeline is not included in the list of runnable pipelines as the script requires additional work to enable that capability.
0 commit comments