Implementing the Platform¶
This section describes how a platform team implements the Managed Cloud Platform (MCP) in a new tenant, from the first workshop to the hand-over. It is written for the platform team: XMMS engineers who deliver the platform under a managed-service contract, or the customer's own engineers who implement it themselves (Operating models). Contract details such as workshop length, contacts and invoicing are not part of the product. They are written as placeholders and come from your contract or project plan.
An implementation builds, in this order, everything that the day-to-day pages in Platform assume:
- the identities, groups, management group and subscriptions the platform needs,
- the repositories and the pipelines that run on self-hosted agents,
- the hub (the canary platform environment first, then prod),
- one test spoke, and
- the proof that all of this works, and a hand-over.
Phases¶
flowchart LR
plan["1. Plan"] --> prepare["2. Prepare"] --> deploy["3. Deploy"] --> validate["4. Validate"] --> close["5. Closure"]| Phase | Result | Pages |
|---|---|---|
| 1. Plan | Signed-off scope, a workshop output (design document or discovery sheet), known stakeholders, an implementation plan, and a list of what the customer must arrange | Plan, Prerequisites, Discovery output to deployment input |
| 2. Prepare | Identities, groups and permissions in place, repositories created, state storage ready, pipelines and agents prepared | Identity, Repositories, Pipelines and agents, GitHub variant, Spoke pipeline, Spoke integrations, Module source access |
| 3. Deploy | Job runners, the mcp image, the hub in canary and prod, and a first spoke |
Deploy the platform, Deploy the spoke canvas |
| 4. Validate | A second person has checked the result against a checklist and recorded it | Validate |
| 5. Closure | Technical hand-over held, delivery accepted, next steps agreed | Hand-over and reporting |
Two more pages cover work that sits beside a new implementation:
| I want to… | Read |
|---|---|
| Move spokes or hubs from an older platform version or from bicep-based spokes | Migrating from an older platform version |
| Remove a demo, test or failed deployment, or redeploy from scratch | Cleaning up a demo or test deployment |
How the implementation relates to the deploy flow¶
The platform deploy flow describes the technical order: infrastructure, container, hub, spokes. The implementation adds what must exist before that order can start (the prepare phase) and what you do after it (validate and hand over). Where a page here and a page in Platform overlap, this section gives the sequence and the checklists, and the other page gives the details.
Roles in an implementation¶
| Role | Responsibility |
|---|---|
| Engagement lead | Runs the meetings and the progress and risk reports. Owns the plan. |
| Architect | Translates the customer's input into values the deployment engineer can use. Talks to the customer about configuration choices. |
| Deployment engineer | Performs the preparation and the deployments from the delivered input. |
| Second person | Validates the deployment. A different person than the deployment engineer. |
| Customer counterparts | Typically an Azure architect, a network engineer, a DevOps engineer, an Azure engineer, a security specialist and a project or delivery manager. They arrange the prerequisites and approve the design. |
In the self-managed model one team fills several of these roles. Keep the second person separate where you can: the four-eyes principle applies to the implementation as well.
Skills the deployment engineer needs¶
| Area | Skill |
|---|---|
| Infrastructure as code | Terraform and *.tfvars files; PowerShell scripting at a basic level |
| Life-cycle management | Azure DevOps (repositories, pipelines, variable groups, project settings, agent pools, service connections) or GitHub (Actions, environments, apps, rulesets); Git |
| Cloud | Azure infrastructure, landing zones and the Cloud Adoption Framework |
| Identity | Microsoft Entra ID: groups, service principals, roles, administrative units, PIM |
Operating-model notes¶
- Managed (XMMS): the platform team works in the customer's tenant, usually as guest users, through a group with eligible (PIM) access. The customer arranges the prerequisites before the preparation starts.
- Self-managed: the same steps apply, but your own team holds the roles and the customer-side prerequisites are internal ones (for example your cloud platform owner arranging subscriptions and groups). At the end, the day-one checklist lists what to set to your own values.