Het platform implementeren¶
Dit onderdeel beschrijft hoe een platformteam het Managed Cloud Platform (MCP) in een nieuwe tenant implementeert, van de eerste workshop tot de overdracht. Het is geschreven voor het platformteam: XMMS-engineers die het platform leveren onder een managed-service-contract, of de eigen engineers van de klant die het zelf implementeren (Beheermodellen). Contractdetails zoals de duur van de workshop, contactpersonen en facturatie maken geen deel uit van het product. Ze staan als placeholders en komen uit je contract of projectplan.
Een implementatie bouwt, in deze volgorde, alles wat de dagelijkse pagina's in Platform veronderstellen:
- de identiteiten, groepen, management group en subscriptions die het platform nodig heeft,
- de repositories en de pipelines die op self-hosted agents draaien,
- de hub (eerst de canary-platformomgeving, daarna prod),
- één test-spoke, en
- het bewijs dat dit allemaal werkt, plus een overdracht.
Fasen¶
flowchart LR
plan["1. Plan"] --> prepare["2. Prepare"] --> deploy["3. Deploy"] --> validate["4. Validate"] --> close["5. Closure"]| Fase | Resultaat | Pagina's |
|---|---|---|
| 1. Plan | Goedgekeurde scope, de uitkomst van een workshop (ontwerpdocument of discovery sheet), bekende stakeholders, een implementatieplan en een lijst van wat de klant moet regelen | Plan, Vereisten, Van discovery-uitkomst naar deployment-invoer |
| 2. Prepare | Identiteiten, groepen en rechten aanwezig, repositories aangemaakt, state storage klaar, pipelines en agents voorbereid | Identiteit, Repositories, Pipelines en agents, GitHub-variant, Spoke pipeline, Spoke-integraties, Toegang tot modulebronnen |
| 3. Deploy | Job runners, de mcp image, de hub in canary en prod, en een eerste spoke |
Het platform uitrollen, De spoke canvas uitrollen |
| 4. Validate | Een tweede persoon heeft het resultaat getoetst aan een checklist en vastgelegd | Valideren |
| 5. Closure | Technische overdracht gehouden, oplevering geaccepteerd, vervolgstappen afgesproken | Overdracht en rapportage |
Twee andere pagina's behandelen werk dat naast een nieuwe implementatie ligt:
| Ik wil… | Lees |
|---|---|
| Spokes of hubs migreren vanaf een oudere platformversie of vanaf spokes op basis van bicep | Migreren vanaf een oudere platformversie |
| Een demo-, test- of mislukte deployment verwijderen, of opnieuw vanaf nul uitrollen | Een demo- of testdeployment opruimen |
Hoe de implementatie zich verhoudt tot de deploy flow¶
De platform deploy flow beschrijft de technische volgorde: infrastructure, container, hub, spokes. De implementatie voegt toe wat er moet zijn voordat die volgorde kan beginnen (de prepare-fase) en wat je daarna doet (valideren en overdragen). Waar een pagina hier en een pagina in Platform overlappen, geeft dit onderdeel de volgorde en de checklists, en de andere pagina de details.
Rollen in een implementatie¶
| Rol | Verantwoordelijkheid |
|---|---|
| Engagement lead | Leidt de meetings en de voortgangs- en risicorapportages. Is eigenaar van het plan. |
| Architect | Vertaalt de input van de klant naar waarden die de deployment engineer kan gebruiken. Overlegt met de klant over configuratiekeuzes. |
| Deployment engineer | Voert de voorbereiding en de deployments uit op basis van de aangeleverde input. |
| Tweede persoon | Valideert de deployment. Een andere persoon dan de deployment engineer. |
| Tegenhangers bij de klant | Meestal een Azure-architect, een netwerkengineer, een DevOps-engineer, een Azure-engineer, een securityspecialist en een project- of deliverymanager. Zij regelen de vereisten en keuren het ontwerp goed. |
In het zelfbeheermodel vervult één team meerdere van deze rollen. Houd de tweede persoon waar mogelijk gescheiden: het vierogenprincipe geldt ook voor de implementatie.
Vaardigheden die de deployment engineer nodig heeft¶
| Gebied | Vaardigheid |
|---|---|
| Infrastructure as code | Terraform en *.tfvars-bestanden; PowerShell-scripting op basisniveau |
| Life-cycle management | Azure DevOps (repositories, pipelines, variable groups, projectinstellingen, agent pools, service connections) of GitHub (Actions, environments, apps, rulesets); Git |
| Cloud | Azure-infrastructuur, landing zones en het Cloud Adoption Framework |
| Identiteit | Microsoft Entra ID: groepen, service principals, rollen, administrative units, PIM |
Opmerkingen per beheermodel¶
- Managed (XMMS): het platformteam werkt in de tenant van de klant, meestal als gastgebruikers, via een groep met eligible (PIM) toegang. De klant regelt de vereisten voordat de voorbereiding begint.
- Zelfbeheer: dezelfde stappen gelden, maar je eigen team vervult de rollen en de vereisten aan klantzijde zijn interne vereisten (bijvoorbeeld je cloud platform owner die subscriptions en groepen regelt). Aan het eind staat in de day-one checklist wat je op je eigen waarden moet zetten.