Die Plattform implementieren¶
Dieser Abschnitt beschreibt, wie ein Plattform-Team die Managed Cloud Platform (MCP) in einem neuen Tenant implementiert, vom ersten Workshop bis zur Übergabe. Er richtet sich an das Plattform-Team: XMMS-Engineers, die die Plattform im Rahmen eines managed-service-Vertrags liefern, oder die eigenen Engineers des Kunden, die sie selbst implementieren (Betriebsmodelle). Vertragsdetails wie Workshop-Dauer, Ansprechpersonen und Rechnungsstellung sind nicht Teil des Produkts. Sie stehen als Platzhalter und stammen aus deinem Vertrag oder Projektplan.
Eine Implementierung baut in dieser Reihenfolge alles auf, was die Alltagsseiten unter Plattform voraussetzen:
- die Identitäten, Gruppen, management group und subscriptions, die die Plattform braucht,
- die Repositories und die pipelines, die auf selbst gehosteten Agents laufen,
- den hub (zuerst die canary-Plattform-Umgebung, dann prod),
- einen Test-spoke und
- den Nachweis, dass all das funktioniert, sowie eine Übergabe.
Phasen¶
flowchart LR
plan["1. Plan"] --> prepare["2. Prepare"] --> deploy["3. Deploy"] --> validate["4. Validate"] --> close["5. Closure"]| Phase | Ergebnis | Seiten |
|---|---|---|
| 1. Plan | Freigegebener Scope, ein Workshop-Ergebnis (Design-Dokument oder Discovery-Sheet), bekannte Stakeholder, ein Implementierungsplan und eine Liste dessen, was der Kunde bereitstellen muss | Plan, Voraussetzungen, Discovery-Ergebnis zu Deployment-Eingabe |
| 2. Prepare | Identitäten, Gruppen und Berechtigungen vorhanden, Repositories erstellt, state-Storage bereit, pipelines und Agents vorbereitet | Identität, Repositories, Pipelines und Agents, GitHub-Variante, Spoke-pipeline, Spoke-Integrationen, Zugriff auf Modulquellen |
| 3. Deploy | Job runners, das mcp-Image, der hub in canary und prod und ein erster spoke |
Die Plattform deployen, Den spoke canvas deployen |
| 4. Validate | Eine zweite Person hat das Ergebnis anhand einer Checkliste geprüft und dokumentiert | Validierung |
| 5. Closure | Technische Übergabe durchgeführt, Lieferung abgenommen, nächste Schritte vereinbart | Übergabe und Reporting |
Zwei weitere Seiten behandeln Arbeiten neben einer neuen Implementierung:
| Ich möchte… | Lies |
|---|---|
| spokes oder hubs von einer älteren Plattform-Version oder von Bicep-basierten spokes migrieren | Von einer älteren Plattform-Version migrieren |
| ein Demo-, Test- oder gescheitertes Deployment entfernen oder von Grund auf neu deployen | Ein Demo- oder Test-Deployment aufräumen |
Wie die Implementierung mit dem Deploy-Flow zusammenhängt¶
Der Deploy-Flow der Plattform beschreibt die technische Reihenfolge: infrastructure, container, hub, spokes. Die Implementierung ergänzt, was vorhanden sein muss, bevor diese Reihenfolge beginnen kann (die Prepare-Phase), und was du danach tust (Validierung und Übergabe). Wo sich eine Seite hier und eine Seite unter Plattform überschneiden, liefert dieser Abschnitt die Reihenfolge und die Checklisten, und die andere Seite die Details.
Rollen in einer Implementierung¶
| Rolle | Verantwortung |
|---|---|
| Engagement Lead | Leitet die Meetings und die Fortschritts- und Risikoberichte. Verantwortet den Plan. |
| Architekt | Übersetzt die Eingaben des Kunden in Werte, die der Deployment Engineer verwenden kann. Spricht mit dem Kunden über Konfigurationsentscheidungen. |
| Deployment Engineer | Führt die Vorbereitung und die Deployments anhand der gelieferten Eingabe durch. |
| Zweite Person | Validiert das Deployment. Eine andere Person als der Deployment Engineer. |
| Ansprechpersonen des Kunden | Typischerweise ein Azure-Architekt, ein Netzwerk-Engineer, ein DevOps-Engineer, ein Azure-Engineer, ein Security-Spezialist und ein Projekt- oder Delivery-Manager. Sie sorgen für die Voraussetzungen und genehmigen das Design. |
Im Eigenbetrieb füllt ein Team mehrere dieser Rollen aus. Halte die zweite Person nach Möglichkeit getrennt: Das Vier-Augen-Prinzip gilt auch für die Implementierung.
Fähigkeiten, die der Deployment Engineer braucht¶
| Bereich | Fähigkeit |
|---|---|
| Infrastructure as Code | Terraform und *.tfvars-Dateien; PowerShell-Scripting auf Grundlagenniveau |
| Life-Cycle-Management | Azure DevOps (Repositories, pipelines, variable groups, Projekteinstellungen, agent pools, service connections) oder GitHub (Actions, environments, apps, rulesets); Git |
| Cloud | Azure-Infrastruktur, landing zones und das Cloud Adoption Framework |
| Identität | Microsoft Entra ID: Gruppen, Service Principals, Rollen, Administrative Units, PIM |
Hinweise zum Betriebsmodell¶
- Managed (XMMS): Das Plattform-Team arbeitet im Tenant des Kunden, meist als Gastbenutzer, über eine Gruppe mit eligible-Zugriff (PIM). Der Kunde sorgt für die Voraussetzungen, bevor die Vorbereitung beginnt.
- Eigenbetrieb: Es gelten dieselben Schritte, aber dein eigenes Team hält die Rollen, und die Voraussetzungen auf Kundenseite sind interne (zum Beispiel dein Cloud Platform Owner, der subscriptions und Gruppen bereitstellt). Am Ende listet die Day-one-Checkliste, was du auf deine eigenen Werte setzen musst.