Anfragen und Änderungen

Alle Änderungen an der Plattform sind Standardänderungen: Du beschreibst, was du willst, die Änderung wird in der Terraform- Konfiguration gemacht, geprüft und von der pipeline deployt. Du änderst Workspaces, Connections, Gateways oder Storage nicht im Azure-Portal oder im Fabric-Portal, weil der nächste pipeline-Lauf die Änderung zurücknehmen würde.

Welchen Intake du nutzt, hängt von deiner Plattform ab (Betriebsmodelle).

Wie eine Änderung abläuft

Eine Änderung hat immer ein Ticket (den Nachweis) und einen pull request auf dem Plattform-Repository (die Änderung).

flowchart TD
    A["You raise a request"] --> B["Ticket in your own Azure DevOps or GitHub"]
    B --> C{"Enough information and in the platform team's scope?"}
    C -->|"yes"| D["Platform team makes the Terraform change and opens a pull request"]
    C -->|"no, it is in your scope"| E["Platform team points to the place in the repository, you open the pull request"]
    D --> F["Review and approval by the platform team"]
    E --> F
    F --> G["Pipeline deploys the change"]
    G --> H["Ticket updated and closed"]

Zwei Wege führen zu einem Ticket:

Weg	Wie es funktioniert
Self-Service-Portal	Im Managed-Modell kannst du die Anfrage im Xebia-Self-Service-Portal (Cloud Command) einreichen. Es erstellt ein Ticket in deiner eigenen Entwicklungsumgebung (Azure DevOps oder GitHub), sodass die Anfrage in deinem Tooling sichtbar und nachvollziehbar ist.
Dein eigenes Tooling	Du erstellst das Ticket direkt in deinem Azure DevOps oder GitHub. Im Managed-Modell wird es mit dem Tooling des Plattform-Teams synchronisiert.

Zwei Lieferwege führen vom Ticket zu einem pull request:

Weg	Wann	Was passiert
Vom Plattform-Team bearbeitet	Die Anfrage enthält genug Informationen	Das Plattform-Team macht die Terraform-Änderung, öffnet den pull request auf dem Plattform-Repository und verlinkt ihn am Ticket
Vom Workload-Team umgesetzt	Die Änderung liegt in deinem Verantwortungsbereich	Das Plattform-Team kommentiert am Ticket die Stelle im Repository, an der du den pull request öffnest. Das Plattform-Team prüft und genehmigt ihn.

Der Fortschritt ist am Ticket und am verlinkten pull request sichtbar. Nach der Genehmigung deployt die pipeline die Änderung.

Im Eigenbetrieb ist der Intake der deines eigenen Teams (Betriebsmodelle); der Ablauf ist derselbe.

Keine manuellen Änderungen

Das Repository ist die Single Source of Truth. Manuelle Änderungen an verwalteten Ressourcen werden beim nächsten Lauf zurückgenommen. Was du selbst in einem Workspace hinzufügst (zum Beispiel zusätzliche Rollenzuweisungen durch einen Workspace-Admin oder deine eigenen Items), wird nicht von Terraform verwaltet und bleibt bestehen. Siehe Zugriff und Rollen.

Was du anfragen kannst

Anfrage	Hinweise
Neuer Workspace	Name Key, Capacity, Rollengruppen, optionale Git-Verknüpfung. Siehe Neuer Workspace.
Rollengruppen ändern	Admins, Contributors, Members, Viewers.
Ein Lakehouse oder Warehouse erstellen oder löschen	Namen müssen über die Lakehouses und Warehouses eines Workspaces eindeutig sein.
ADLS-, SQL- oder Oracle-Cloud-Storage-Connection	Siehe Konnektivität.
Workspace-zu-Workspace-Connection oder Managed Private Endpoint	Siehe Konnektivität.
Git-Verknüpfung	Siehe Konnektivität.
Die Capacity skalieren oder die SKU ändern	Ändert die Kosten. Siehe Kostenoptimierung.
Neuer Storage-Container	Wird durch Hinzufügen einer ADLS-Connection erledigt.

Gib bei einer Anfrage immer an: die Umgebung und den Workspace, was du geändert haben willst, und warum (es landet als Änderungsnachweis im Ticket).

Neuer Workspace

Feld	Erforderlich	Hinweise
Umgebung	ja	development, test, acceptance oder production
Workspace Key	ja	Teil des Workspace-Namens (<workload>-<env>-<region>-<key>).
Capacity	ja	Der Capacity Key, der verwendet werden soll. Es muss eine Capacity sein, die die Plattform für die Umgebung definiert hat.
Gruppe für jede Rolle	nein	Contributors, Members, Viewers und die optionale Admin-Gruppe. Gib die Object-ID einer Entra-ID-Sicherheitsgruppe an, oder ihren Anzeigenamen. Die ID gewinnt, wenn beides angegeben ist.
Outbound Network Policy	nein	Default ist die geschützte Einstellung (outbound deny). Lies Workspace Network Policy, bevor du einen anderen Wert anfragst.
Git-Verknüpfung	nein	Owner, Repository, Branch und Verzeichnis. Das Verzeichnis muss im Repository bereits existieren, sonst schlägt das Deployment fehl.
Lakehouses	nein	Name, Beschreibung und ob Schemas aktiviert sind
Warehouses	nein	Name, Beschreibung und Collation: Latin1_General_100_BIN2_UTF8 oder Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Eine Rolle pro Gruppe

Fabric erlaubt pro Workspace eine Rolle pro Principal. Dieselbe Gruppe kann nicht Admin und Contributor sein. Der plan meldet Duplikate (siehe Zugriff und Rollen).

Connections und ihre Secrets

Für ADLS-, SQL- und Oracle-Cloud-Storage-Connections gibst du in der Anfrage keine Zugangsdaten an. Die Zugangsdaten sind Secrets im Key Vault des spokes. Die Konfiguration verweist per Secret-Namen darauf, und du oder dein Identity-Team legt das Secret im Vault ab. Frag das Plattform-Team nach dem Vault und den vereinbarten Secret-Namen. Details und Felder stehen unter Konnektivität.

Was das Plattform-Team prüft

Prüfung	Warum
Der plan zeigt nur die erwarteten Änderungen	Workspaces dürfen nicht versehentlich neu erstellt werden
Gruppen-IDs sind korrekt und pro Workspace eindeutig	Fabric lehnt Duplikate ab
Secret-Namen existieren im Key Vault	Die Connection-Ressourcen lesen sie zur plan-Zeit
Der Capacity Key existiert	Sonst schlägt die Validierung fehl
Die Änderung der Capacity-SKU passt zum Budget	Kostenauswirkung

Nach dem Deployment

Du bekommst eine Nachricht am Ticket. Rollenzuweisungen sind sofortige, störungsfreie API-Aufrufe und lassen sich zurückrollen, indem du sie aus der Konfiguration entfernst. Das VNet Data Gateway schläft, wenn es nicht genutzt wird, und wacht bei der nächsten Anfrage auf, daher kann die erste Nutzung nach einer ruhigen Phase langsamer sein.