Prepare the Spoke Pipeline¶

This page covers what you prepare so that spokes can be deployed from a pipeline: the identity that deploys spokes, access to the code, the service connections, and the pipeline itself. It describes the separate spoke canvas deployment: a spoke code repository, a spoke configuration repository or folder, and its own pipeline. This is the layout of earlier platform versions, and some implementations still use it. In the current layout, the entry pipeline spoke in the configuration repository calls the code repository, and most steps here are already covered by Prepare identity and Prepare repositories. Use the table to see what applies.

Topic	Current layout	Separate spoke canvas deployment
Spoke identity and permissions	Prepare identity	Spoke deployment identity
Code access	One code repository, pinned in the entry pipeline	Where the code lives
Service connections	Prepare identity	Service connections
Pipeline	Entry pipeline `spoke` (Pipelines)	Create the pipeline
Spoke settings	`mcp.json` `SpokeCommon`	`common.tf` (Spoke common settings)

Before you start, the groups, administrative unit and management group from Prepare identity must exist. Who does what depends on the operating model.

Spoke deployment identity¶

Create a service principal that is dedicated to spoke deployment. A dedicated identity can be limited to what spokes need. Create two with equal rights: one for the canary platform environment and one for production.

Where	Requirement
Management group	Owner on the `landingzone` management group of its environment. The canary identity gets the canary one, the production identity the production one.
Microsoft Graph, application permissions	The list in Prepare identity, with admin consent
Administrative unit	Groups Administrator on the administrative unit that holds the spoke groups

The list of Graph permissions in the documentation of the code version you pin is leading.

Where the code lives¶

The Terraform of the spoke deployment is a code repository. There are two ways to give the pipeline access to it. The first is the standard.

Option 1: the code stays with the platform team (standard)¶

The pipeline reads the code from the platform team's repository through a service connection. You only need this when the parameters repository (the one with the spoke files) is not in the same organization as the code.

Sign in to the Azure DevOps organization that holds the parameters, and open the project.
Project settings, Service connections, New service connection.
Choose Azure Repos/Team Foundation Server, then Token based authentication.
Fill in:
- Connection URL: the URL of the code repository <code repository URL>.
- Personal access token: a token of the platform team's organization with read access to that repository.
Choose Verify, give the connection a name and description, then Verify and save.

Treat the token as a secret

A personal access token expires and belongs to a person. Agree who renews it and when, and put the expiry date in the maintenance calendar (Secret watcher).

Option 2: the code is hosted in the customer organization¶

Use this when the customer wants the code in their own organization.

In the customer project, Repos, New repository. Name it as the pipeline expects (the example uses spokedeployment-tf), type Git.
Clone it, copy the contents of the platform team's code repository into it, and push.
Check that the push succeeded.

You are then responsible for updating that copy when a new version is released (Versioning). Keep it read-only for everyone except the identity that updates it (Prepare repositories).

Service connections for the spoke identities¶

Create an Azure Resource Manager service connection for each of the two identities. Repeat the steps for canary and production.

In the project, Project settings, Service connections, New service connection, Azure Resource Manager.
Choose Service principal (manual) and Management Group as the scope.

Fill in:

Field	Value
Management group ID and name	The `landingzone` management group of this environment: under the canary tree for the canary identity, under the production tree for the production identity.
Service principal ID	Client ID of the service principal
Service principal key	Client secret
Tenant ID	The customer tenant
Service connection name	For example `SpokeDeployment_Prd` and `SpokeDeployment_Canary`

Choose Verify, then Save.

Take the secret from your secret store. Prefer workload identity federation where your version supports it.

Create the pipeline¶

In the project, Pipelines, New pipeline (or Create pipeline when it is the first one).
Where is your code: Azure Repos Git. Select the repository that holds the pipeline code.
Configure your pipeline: Existing Azure Pipelines YAML file. Branch main. Path: the spoke pipeline file of your layout (the example uses /pipelines/SpokeDeployment.yaml).
Open the Run menu and choose Save. Do not run it yet.
In the pipeline list (All), open the menu of the pipeline, Rename/move, and give it a clear name, for example Landing Zone - Spoke deployment.

The pipeline starts automatically when a pull request is merged into main, as described in New spoke.

Parameters in a different repository¶

The spoke files can be in another repository, for example on GitHub, than the pipeline. Add the repository as a resource and pass its name to the stage templates:

resources:
  repositories:
    - repository: spoke-canvas-params
      endpoint: <GitHub service connection>
      type: github
      name: <organization>/<repository>
      ref: main

stages:
  - template: /pipelines/templates/stages/prepare-matrix.yaml@<code repository resource>
    parameters:
      checkout: spoke-canvas-params
      stageId: prepStage
  - template: /pipelines/templates/stages/deploy-matrix.yaml@<code repository resource>
    parameters:
      checkout: spoke-canvas-params
      stageId: deployStage

<GitHub service connection> is a GitHub service connection that you add to the Azure DevOps project. Template paths and resource names are the ones of your version; the example shows the idea, not the exact file. Do not copy it without checking it against the entry pipeline you have.

Create subscriptions¶

The spoke deployment needs an existing subscription. In the separate layout a second pipeline can create it, but the subscription creation was not final in the source documentation and needs billing information of a CSP account. Read New spoke first. If you do use a subscription pipeline:

Create it in the same way as above, with the file of your version (the example uses /pipelines/create-subscription.yaml) and a name such as Landing Zone - Create Spoke Subscription.
Run it with the workload short name, the environment and the management group.
Open the run, the Terraform apply step, and read subscription_id from the output. You need it in the spoke file.

Check¶

[ ] Two spoke identities exist (canary and production) with Owner on their landingzone management group
[ ] Graph permissions are consented, and the administrative unit role is assigned
[ ] The pipeline can read the code (service connection verified, or the copy exists)
[ ] Two Azure Resource Manager service connections exist and verify
[ ] The pipeline exists and is saved
[ ] If the spoke creates Azure DevOps or GitHub resources: Prepare spoke integrations

Next: Deploy the spoke canvas.