Anfragen und Änderungen¶
Fast jede Änderung an der Integration Platform ist eine Standardänderung: Du beschreibst, was du willst, das Plattform-Team oder du (über einen pull request) ändert die Konfiguration im Code, sie wird geprüft und deployt. Du legst queues, topics oder Integrationsressourcen nicht von Hand im Portal an, weil das nächste Deployment es rückgängig machen würde.
Welchen Intake du nutzt, hängt von deiner Plattform ab (Betriebsmodelle). support-Zeiten,
Reaktions- und Lösungsziele und der Kontaktkanal (<support channel>) stehen in deiner Vereinbarung, nicht hier.
Wie Änderungen gemacht werden¶
| Form | So funktioniert es |
|---|---|
| Anfrage | Du beschreibst die Änderung in einem Ticket oder Work Item. Das Plattform-Team bereitet den pull request vor. |
| Pull request | Du änderst die Konfiguration selbst (zum Beispiel queues.json oder den Modulaufruf deines Workload-Repositorys) und öffnest einen pull request. Das Plattform-Team oder die integration platform engineers prüfen und deployen ihn. Die Plattform akzeptiert pull requests von builders, auch um ihre eigenen Prozesse zu verbessern. |
Jede Interaktion mit der Plattform läuft über Git und pull request, was Versionskontrolle und Nachvollziehbarkeit gibt. Die Schritte sind:
- Die Änderung ist ein pull request, von dir oder auf Anfrage vorbereitet.
- Ein Reviewer prüft ihn. Für Service-Bus-Entitäten siehe die Checkliste.
- Er wird über die pipeline deployt. Deployments deiner eigenen Workload-Ressourcen werden von Hand gestartet (Integrationsressourcen deployen).
- Du wirst informiert, und das Ticket wird geschlossen.
Standardänderungen¶
| Änderung | Klasse | Was du lieferst | Wo es konfiguriert wird |
|---|---|---|---|
| Einen Shared Service ein- oder ausschalten (Service Bus, Event Hubs, API Management, Container Registry) | Optimisation | Den Service, die Umgebungen und wer ihn nutzen wird | Spoke-Datei, Extension enabled (Spoke extensions) |
| Einen Integration-workload-spoke an die Shared Services anbinden | Enablement | Den spoke und die Extensions, die du brauchst | Spoke-Datei (Spoke JSON) |
| Eine Service-Bus-queue oder ein topic hinzufügen, ändern oder entfernen | Enablement | Die Entität, ihre Eigenschaften, Producer- und Consumer-workloads | queues.json oder topics.json (Service Bus) |
| Personen oder Gruppen in einer Sender- oder Receiver-Gruppe von Service Bus hinzufügen oder entfernen | Enablement | Die Gruppe, die Mitglieder | Entra ID. Das kannst du als Owner der Gruppe selbst tun. |
| Eine API in API Management und im Application Gateway hinzufügen, ändern oder entfernen | Enablement | Die API-Definition, Backend, Products, Subscriptions | APIOps-Repository und Gateway-Definitionen (Shared Services) |
| Ein neues Integrationsmuster oder Modul anfragen (Logic App, Function App, Container App, Data Factory) | Enablement | Das Modul, spoke, Umgebung und Einstellungen | Modulaufruf in deinem Workload-Repository (Module) |
| integration platform engineers hinzufügen | Enablement | Die Personen und die Rolle | Plattformzugriff, laut deiner Vereinbarung |
Änderungen außerhalb dieser Liste, etwa eine neue Modul-Option oder ein neuer Shared Service, sind Änderungen der Plattform und keine Standard- änderungen. Sie werden zuerst bewertet (Servicetypen).
Was in eine Anfrage gehört¶
| Anfrage | Angeben |
|---|---|
| Shared Service oder Extension | Den spoke, den Service (apim, acr, servicebus, eventhub), die Umgebungen, die Personen, die ihn nutzen werden |
| Queue oder topic | Workload, Entitätsnamen, queue oder topic und bei einem topic die abonnierenden workloads. Eigenschaften, die von den Standardwerten abweichen (Delivery Count, TTL, sessions, Duplicate Detection, Größe). Ob eine Filterregel nötig ist. |
| Modul | Welches Modul, den spoke und die Umgebung, die zu nutzenden Subnet-Namen, Größen, die Identität zum Pullen von Images (Container App), Authentifizierungseinstellungen (Logic App) |
| API | Name, path, Backend-URL, OpenAPI-Datei, Products, Subscriptions. Keine Keys in der Anfrage: Verweise auf Key-Vault-Secrets. |
| Firewallregel | Quelle, Ziel (FQDN oder IP group), Port. Nötig für jede Verbindung, die deinen spoke verlässt (Firewallregeln und IP groups). |
Wer macht was¶
| Plattform-Team | Workload-Team | |
|---|---|---|
| Shared Services und die Plattform-pipelines deployen und betreiben | Ja | |
| Änderungen an Entitäten und Modulen prüfen und deployen | Ja | Den pull request vorbereiten |
| Gruppenmitgliedschaft deiner Entitäten verwalten | Ja | |
| Über die Eigenschaften deiner queues, APIs und Ressourcen entscheiden | Ja | |
| Firewallregeln | Validieren und deployen | Anfragen |
Die generische Aufteilung steht in Verantwortlichkeiten und Betriebsmodell.