Freigeben über

Plattformautomatisierung und DevOps für den API Management Landing Zone Accelerator

Dieser Artikel enthält Entwurfsüberlegungen und Empfehlungen für die Plattformautomatisierung und DevOps bei Verwendung des API Management Landing Zone Accelerator. Plattformautomatisierung und DevOps bieten Möglichkeiten, Ihren Ansatz für die Umgebungsbereitstellung mit Infrastruktur-as-Code-Optionen zu modernisieren.

Erfahren Sie mehr über den Plattformautomatisierungs- und DevOps-Entwurfsbereich .

Entwurfsüberlegungen

  • Jedes API-Team kann Updates von einem eigenen Entwickler-Repository an eine eigene Entwicklungs-API-Verwaltungsinstanz übertragen.
    • Was bedeutet dies aus der Perspektive der Netzwerkplanung?
    • Was ist mit anderen Nichtproduktionsumgebungen (z. B. QA oder Staging)?
  • Überlegen Sie, wie Produkte und andere Entitäten verwaltet oder versioniert werden sollen, insbesondere, wenn mehrere Teams dieselben Produkte verwenden.
  • Berücksichtigen Sie die Teststrategie für APIs und Richtlinien.

Designempfehlungen

  • Ein zentrales Team (z. B. ein API-Verwaltungsadministratorteam) verwaltet die Produktions-API-Verwaltungsumgebung.
  • API-Verwaltungskonfigurationen werden als Ressourcen-Manager-Vorlagen oder gleichwertige Bicep- oder Terraform-Vorlagen dargestellt, und eine Infrastruktur-as-Code-Denkweise sollte übernommen werden.
  • Das API Management-Administratorteam veröffentlicht Konfigurationsänderungen in der Produktions-API-Verwaltungsumgebung aus einem Git-Repository (Herausgeber-Repository) im Besitz des API-Verwaltungsadministratorteams.
  • Jedes einzelne API-Team kann das Herausgeber-Repository verzweigen, um ein eigenes Entwickler-Repository zu verwenden.
  • Jedes Team kann die API-Verwaltungs-APIOps oder die API-Verwaltungserweiterung für Visual Studio Code verwenden, um die relevanten Artefakte aus ihrer Entwicklungs-API-Verwaltungsinstanz zu extrahieren. Diese Artefakte basieren auf Azure Resource Manager und sollten im Git-Repository des API-Teams abgelegt werden.

    Hinweis

    Verwenden Sie nicht die Git-Integration im API Management.

  • Dienstvorlagen und freigegebene Vorlagen sollten sich in separaten Repositorys befinden.
  • Änderungen an Artefakten sollten an den extrahierten Artefakten vorgenommen und dann nach Git committet werden. Diese sollten in einer Entwicklungsumgebung bereitgestellt werden.
  • Um die zentralisierten Umgebungen (Staging, Produktion usw.) zu fördern, können API-Teams einen Pull Request (PR) übermitteln, um ihre Änderungen am Herausgeber-Repository zusammenzuführen.
  • Das API-Verwaltungsadministratorteam überprüft die PR.
    • Im Idealfall werden die meisten Validierungen im Rahmen der Einreichung einer PR automatisiert.
  • Die Infrastruktur-as-Code-Vorlagen sollten sich in einem anderen Repository befinden und in einer Bereitstellungspipeline bereitgestellt werden.
    • Trennen Sie die Infrastrukturbereitstellung von der Anwendungsbereitstellung. Die Kerninfrastruktur ändert sich weniger häufig als Anwendungen. Behandeln Sie jeden Bereitstellungstyp als einen separaten Fluss und eine separate Pipeline.
  • Nachdem Änderungen erfolgreich genehmigt und zusammengeführt wurden, kann das API-Verwaltungsadministratorteam die Änderungen in der zentral verwalteten Umgebung (Staging, Produktion) in Abstimmung mit vereinbarten API-Teamzeitplänen bereitstellen.

Unternehmensweite Annahmen

Die folgenden Annahmen wurden bei der Entwicklung des API Management-Zielzonenbeschleunigers einbezogen:

  • Verwenden von Infrastructure-as-Code-Bicep-Dateien zur Bereitstellung der Infrastruktur für die API-Verwaltung und die Backends.
  • Bereitstellung von Infrastruktur-Templates mithilfe von Pipelines.

Nächste Schritte