Aanvragen en wijzigen

Alle wijzigingen aan het platform zijn standaardwijzigingen: jij beschrijft wat je wilt, de wijziging wordt doorgevoerd in de Terraform- configuratie, gereviewd en door de pipeline gedeployd. Je wijzigt workspaces, connections, gateways of storage niet in de Azure-portal of de Fabric-portal, want de volgende pipeline-run zou dat ongedaan maken.

Welke intake je gebruikt, hangt af van je platform (Beheermodellen).

Hoe een wijziging verloopt

Een wijziging heeft altijd een ticket (het record) en een pull request op de platformrepository (de wijziging).

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"]

Twee routes leiden naar een ticket:

Route	Hoe het werkt
Self-serviceportal	In het managed model kun je de aanvraag indienen in de self-serviceportal van Xebia (Cloud Command). Die maakt een ticket aan in je eigen ontwikkelomgeving (Azure DevOps of GitHub), zodat de aanvraag zichtbaar en controleerbaar is in je eigen tooling.
Je eigen tooling	Je maakt het ticket direct aan in je Azure DevOps of GitHub. In het managed model wordt het gesynchroniseerd met de tooling van het platformteam.

Twee leveringspaden leiden van het ticket naar een pull request:

Pad	Wanneer	Wat er gebeurt
Afgehandeld door het platformteam	De aanvraag bevat genoeg informatie	Het platformteam maakt de Terraform-wijziging, opent de pull request op de platformrepository en linkt die aan het ticket
Geïmplementeerd door het workload team	De wijziging valt binnen jouw scope of eigenaarschap	Het platformteam reageert op het ticket met de plek in de repository waar je de pull request opent. Het platformteam reviewt en keurt hem goed.

Voortgang is zichtbaar op het ticket en de gekoppelde pull request. Na goedkeuring deployt de pipeline de wijziging.

Bij zelfbeheer is de intake die van je eigen team (Beheermodellen); de flow is hetzelfde.

Geen handmatige wijzigingen

De repository is de enige bron van waarheid. Handmatige wijzigingen aan beheerde resources worden bij de volgende run teruggedraaid. Wat je zelf in een workspace toevoegt (bijvoorbeeld extra role assignments door een workspace-admin, of je eigen items) wordt niet door Terraform beheerd en blijft staan. Zie Toegang en rollen.

Wat je kunt aanvragen

Aanvraag	Opmerkingen
Nieuwe workspace	Naamsleutel, capacity, rolgroepen, optionele Git-koppeling. Zie Nieuwe workspace.
Rolgroepen wijzigen	Admins, contributors, members, viewers.
Een Lakehouse of Warehouse aanmaken of verwijderen	Namen moeten uniek zijn over de Lakehouses en Warehouses van een workspace.
Connection naar ADLS, SQL of Oracle Cloud Storage	Zie Connectiviteit.
Connection van workspace naar workspace of managed private endpoint	Zie Connectiviteit.
Git-koppeling	Zie Connectiviteit.
De capacity schalen of de SKU wijzigen	Verandert de kosten. Zie Kostenoptimalisatie.
Nieuwe storage container	Gebeurt door een ADLS-connection toe te voegen.

Geef bij een aanvraag altijd: de omgeving en workspace, wat je gewijzigd wilt hebben, en waarom (dat komt als wijzigingsrecord op het ticket).

Nieuwe workspace

Veld	Verplicht	Opmerkingen
Omgeving	ja	development, test, acceptance of production
Workspace key	ja	Onderdeel van de workspacenaam (<workload>-<env>-<region>-<key>).
Capacity	ja	De capacity key die je wilt gebruiken. Het moet een capacity zijn die het platform voor de omgeving heeft gedefinieerd.
Groep voor elke rol	nee	Contributors, members, viewers en de optionele admingroep. Geef de Object ID van een Entra ID-securitygroep, of de weergavenaam. De ID wint als beide zijn opgegeven.
Outbound network policy	nee	Standaard is de beschermde instelling (outbound deny). Lees Workspace network policy voor je om een andere waarde vraagt.
Git-koppeling	nee	Owner, repository, branch en map. De map moet al in de repository bestaan, anders mislukt de deployment.
Lakehouses	nee	Naam, beschrijving en of schema's zijn ingeschakeld
Warehouses	nee	Naam, beschrijving en collation: Latin1_General_100_BIN2_UTF8 of Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Eén rol per groep

Fabric staat één rol per principal per workspace toe. Dezelfde groep kan niet Admin en Contributor zijn. Het plan meldt duplicaten (zie Toegang en rollen).

Connections en hun secrets

Voor connections naar ADLS, SQL en Oracle Cloud Storage geef je geen credentials in de aanvraag. De credentials zijn secrets in de Key Vault van de spoke. De configuratie verwijst er op naam naar, en jij of je identiteitsteam zet het secret in de vault. Vraag het platformteam naar de vault en de afgesproken namen van de secrets. Details en velden staan bij Connectiviteit.

Wat het platformteam controleert

Controle	Waarom
Het plan toont alleen de verwachte wijzigingen	Workspaces mogen niet per ongeluk opnieuw worden aangemaakt
Groeps-ID's zijn correct en uniek per workspace	Fabric wijst duplicaten af
Namen van secrets bestaan in de Key Vault	De connectionresources lezen ze tijdens het plan
De capacity key bestaat	Anders mislukt de validatie
Wijziging van de capacity-SKU past in het budget	Kostenimpact

Na de deployment

Je krijgt een bericht op het ticket. Role assignments zijn directe API-aanroepen zonder verstoring en kunnen worden teruggedraaid door ze uit de configuratie te verwijderen. De VNet data gateway slaapt als hij niet wordt gebruikt en wordt bij het volgende verzoek wakker, dus het eerste gebruik na een rustige periode kan trager zijn.