Automatisieren der API-Verwaltungskonfiguration mithilfe der APIOps CLI

Azure API Management

Azure DevOps

Azure Pipelines

GitHub

APIOps ist eine Methode, die die Konzepte von GitOps und DevOps auf die API-Bereitstellung anwendet. Diese Architektur veranschaulicht, wie man mit APIOps CLI die Azure-API-Management-Konfiguration in einem Git-basierten Workflow extrahieren, überprüfen und höherstufen kann. Verwenden Sie diesen Ansatz zum Verwalten des API-Lebenszyklus, zur Verbesserung der API-Qualität und zum Verwalten eines auditierbaren Datensatzes genehmigter Änderungen.

Architektur

Das folgende Diagramm veranschaulicht den High-Level APIOps CLI-Konfigurationsaufwertungsworkflow. Teams überprüfen API-Verwaltungsartefakte in Git und fördern dann kontinuierliche Integration und kontinuierliche Übermittlung (CI/CD)-Pipelines die genehmigte Konfiguration in Ziel-API-Verwaltungsumgebungen.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

Die API-Verwaltungskonfiguration beginnt entweder durch Extrahieren einer vorhandenen API-Verwaltungskonfiguration oder durch Erstellen von CLI-kompatiblen API-Verwaltungsartefakten. Der operative Workflow beginnt mit einem dieser Artefakte als Eingabe. Beide Pfade führen zu derselben Pullanforderung, Überprüfung, Genehmigung und Bereitstellung:

(A) Zuerst extrahieren: Ein API-Operator führt apiops extract für eine vorhandene API Management-Instanz aus, um API Management-Artefaktdateien in seinem lokalen Git-Checkout-Branch zu erstellen. Der Operator verwendet diese Artefakte, um einen Basisplan vorzuschlagen oder eine genehmigte Konfigurationsänderung zu erfassen.
(B) Code-first: Ein API-Entwickler erstellt oder aktualisiert APIOps CLI-kompatible API-Spezifikationen, Informationsdateien, Richtlinien und zugehörige API Management-Artefakte in seinem lokalen Git-Checkout-Branch.

Verwenden Sie den folgenden Lebenszyklus für beide Eingaben:

Erstellen Sie eine Konfigurationsänderung. Nach der ersten Extraktions- oder Code-first-Artefakterstellungsprüfung wird das API-Konfigurationsrepository zur autoritativen Quelle der Wahrheit für API-Verwaltungskonfigurationsartefakte. Das Repository verwaltet den Versionsverlauf und das Audit-Protokoll für jede Bereitstellung. Um eine Änderung vorzunehmen, erstellt ein API-Operator oder Entwickler eine Verzweigung aus der geschützten Verzweigung im API-Konfigurations-Repository und nimmt eine logische Änderung im Zusammenhang mit der API vor.
Überprüfen und validieren Sie die Änderung. Der Operator oder Entwickler öffnet einen Pull Request, um seinen Branch in einen geschützten Branch zusammenzuführen. Die erforderlichen Besitzer und Prüfer des API-Vertrags, der Richtlinien und der API-Verwaltungskonfiguration überprüfen die Pullanforderung. Das CI/CD-System führt die folgenden Prüfungen und Tests aus:
- Linting von API-Spezifikationen
- Erkennung von Breaking Changes im Abgleich mit dem freigegebenen Vertrag
- Sicherheitsüberprüfung von Spezifikationen und Repositoryinhalten
- API-Tests, die erwartetes Verhalten, Authentifizierung, Richtlinieneffekte und Back-End-Abhängigkeiten überprüfen
Für diese Prüfungen sind keine Microsoft Tools erforderlich. Das Team verwendet alle geeigneten Tools, die den Support-, Sicherheits- und Lizenzierungsanforderungen ihrer Organisation erfüllen.
Genehmigen sie die unveränderliche Bereitstellungseingabe. Erforderliche Besitzer oder Prüfer genehmigen die Pull-Anforderung, und ein autorisierter Repository-Betreuer führt die überprüften Änderungen zusammen, nachdem alle erforderlichen Prüfungen und Rezensionen bestanden haben. Der zusammengeführte, unveränderliche Commit und seine geschützten Verzweigungsartefakte werden zur auditierbaren Quelle der Wahrheit des Repositorys.

Das Team schützt die geschützten Repositoryverzweigungen vor direkten Pushs, erfordert Umgebungs- oder Dienstverbindungsgenehmigungen für vertrauliche Ziele und verwendet separate Identitäten mit geringsten Rechten für die Extraktion und Veröffentlichung. Sie dokumentieren den genehmigten Commit mit dem zugehörigen Pull-Request, den Reviews und den Validierungsergebnissen für die Nachvollziehbarkeit bei Audits.
Überprüfen der Bereitstellung. Die CI/CD-Pipeline führt apiops publish --dry-run für den genehmigten Commit mit demselben Ziel und derselben Override-Datei ohne Veröffentlichung aus. Der Veröffentlichungsgenehmiger überprüft die Ressourcen, die der Testlauf erstellt, aktualisiert, löscht oder überspringt. Das Team betrachtet einen erfolgreichen Trockenlauf als Freigabekriterium für die Bereitstellung, nicht als Ersatz für automatisierte API-Tests.
Veröffentlichen und bewerben. Nachdem der Testlauf die Validierung bestanden hat, verwendet die CI/CD-Pipeline apiops publish, um denselben zuvor geprüften Commit zu veröffentlichen. Für den Einsatz in mehreren Umgebungen hält das Plattformteam gemeinsam genutzte Artefakte stabil und verwendet überprüfte Override-Konfigurationsdateien mit Werten wie Back-End-URLs, Ressourcen-IDs und Verweisen auf Secrets. Das Team fördert den Commit durch Nichtproduktion vor der Produktion und verhindert, dass mehrere Pipeline gleichzeitig in dasselbe Ziel schreiben.

Note

Die Konfiguration akzeptiert untergeordnete Arbeitsbereichsüberschreibungen, wendet sie jedoch nicht an, wenn Sie veröffentlichen. Die Veröffentlichung wendet Überschreibungen nur auf den Arbeitsbereichscontainer selbst an. Verlassen Sie sich nicht auf Überschreibungen untergeordneter Arbeitsbereiche, um umgebungsspezifische Arbeitsbereichs-APIs, Backends, benannte Werte oder andere untergeordnete Ressourcen heraufzustufen. Prüfen Sie für diese Ressourcen einen alternativen Ansatz für die Promotion, oder verschieben Sie die Promotion, bis das bekannte Problem Bereichsbezogene Außerkraftsetzungseigenschaften des Arbeitsbereichs werden nicht angewendet behoben ist.
Überprüfen und abgleichen nach der Bereitstellung. Nach der Veröffentlichung führt das Betriebsteam automatisierte Smoke- und Regressionstests aus, überwacht das API-Management sowie den Zustand der Back-End-Dienste und vergleicht das bereitgestellte Ergebnis mit dem genehmigten Commit. Das Team untersucht und löst unerwartete Änderungen durch Pullanforderungen, anstatt die Produktion direkt zu bearbeiten.

Wenn ein API-Operator eine genehmigte Notfalländerung direkt in API Management vornimmt, muss der Operator in einem Git-Checkout eine Extraktion ausführen, die Artefaktänderung auf seinem Branch prüfen und committen, den Branch pushen und einen Pull Request öffnen. Die erforderlichen Besitzer oder Prüfer müssen die Pullanforderung überprüfen und genehmigen, und ein autorisierter Repository-Betreuer muss sie zusammenführen, damit das Repository autoritativ bleibt.

Komponenten

DIE API-Verwaltung ist ein verwalteter Dienst, der konsistente API-Gateways für Back-End-Dienste erstellt. In dieser Architektur werden die Quellkonfigurationen bereitgestellt, die die APIOps CLI extrahiert, und die Zielumgebungen, in denen die CLI genehmigte API-Definitionen, Richtlinien, Produkte, Diagnosen, benannte Werte und andere unterstützte Konfigurationen veröffentlicht.
APIOps CLI ist ein Open-Source-Projekt, das Tools für einen meinungsorientierten APIOps-Ansatz bereitstellt. In dieser Architektur werden API-Management-Konfigurationen in Artefaktdateien extrahiert, Artefakte im API-Management veröffentlicht, und es können CI/CD-Workflows generiert werden.
Ein Git-Repository speichert API-Verwaltungsartefakte und gegebenenfalls API-Verträge. Er stellt den Überprüfungsverlauf und die genehmigte Wahrheitsquelle für Pipelinebereitstellungen bereit.
Ein CI/CD-System führt Validierung, Extraktion und Veröffentlichung mithilfe einer Workloadidentität oder anderer unterstützter nichtinteraktiver Anmeldeinformationen aus. In dieser Architektur definieren GitHub Actions oder Azure Pipelines die CI/CD-Workflows.

Alternativen

Sie können diese Architektur durch andere Azure Dienste oder Ansätze ersetzen oder erweitern, je nach den funktionalen und nichtfunktionellen Anforderungen Ihrer Workload. Berücksichtigen Sie die folgenden Alternativen und Kompromisse.

Bicep oder Terraform und APIOps können verschiedene Teile derselben Lösung bedienen. Ein Team, das sowohl die API-Verwaltungskonfiguration als auch die Infrastruktur besitzt, kann Infrastruktur als Code (IaC) verwenden, um den API-Verwaltungsdienst und seine unterstützende Infrastruktur bereitzustellen und dieselbe IaC-Pipeline zum Verwalten der API-Verwaltungskonfiguration zu verwenden. Wählen Sie diesen Ansatz, wenn Infrastruktur und Konfiguration gemeinsam geändert und bereitgestellt werden und wenn Parameter die Unterschiede zwischen Umgebungen abbilden können.

Verwenden Sie das APIOps-Muster, wenn API-Definitionen, Richtlinien und zugehörige Konfiguration separate Besitzer oder einen release-Lebenszyklus haben, der unabhängig von der Dienstinfrastruktur ist. APIOps ist auch geeignet, wenn Sie vorhandene Konfiguration extrahieren, API-fokussierte Artefakte überprüfen oder dieselbe genehmigte Konfiguration über mehrere Umgebungen oder API-Verwaltungsinstanzen heraufstufen müssen. Häufigere API- und Richtlinienänderungen oder mehr Umgebungen erhöhen den Wert dieses dedizierten Workflows.

Diese Faktoren haben keine festen Schwellenwerte. Stützen Sie die Entscheidung in erster Linie auf Zuständigkeiten, Prüfanforderungen und Grenzen der Bereitstellung. Beginnen Sie bei einem kleineren API-Bestand mit niedriger Änderungsrate mit einem manuellen Pull-Request-Workflow und fügen Sie Zeitpläne für die Extraktion oder Bereitstellungsautomatisierung erst hinzu, nachdem die Ausgangsbasis des Repositorys und der Genehmigungsprozess eingerichtet wurden.

Details zum Szenario

APIOps verwendet die Versionssteuerung, um APIs zu verwalten und einen Überwachungspfad mit Änderungen an API-Definitionen, Richtlinien, Produkten, Diagnosen und anderen API-Verwaltungskonfigurationen zu erstellen. Das Überprüfen von Änderungen früher und häufiger hilft Teams dabei, Abweichungen von API-Standards vor der Bereitstellung zu erkennen. Da mehr APIs denselben Prozess verwenden, können Teams die Konsistenz in der gesamten API-Umgebung verbessern.

Dieser Workflow stellt die API-Verwaltungskonfiguration in einer API-Verwaltungsinstanz bereit. Es stellt keine API-Back-Ends, Anwendungsberechnungs- oder Datenressourcen, Netzwerke oder die API-Verwaltungsdienstinfrastruktur bereit. Verwenden Sie getrennte kontrollierte IaC- und Anwendungs-Pipelines, um diese Ebenen bereitzustellen.

Diese Lösung hilft Teams:

Verwalten Sie einen Überblick über Umgebungen und API-Verwaltungsinstanzen.
Verfolgen Sie wichtige Änderungen an APIs und Richtlinien.
Erstellen Sie einen Überwachungspfad für genehmigte Bereitstellungen.
Gleichen Sie genehmigte Änderungen ab, die außerhalb des Repositorys vorgenommen wurden.

Auswählen von Artefaktquellen und Besitz

Wählen Sie aus, auf welche der folgenden Arten Artefakte in das Repository gelangen und wem sie gehören, bevor Sie die Bereitstellung automatisieren:

Zuerst extrahieren: Extrahieren Sie eine bekanntermaßen funktionsfähige API-Management-Instanz, um die anfängliche Artefakt-Basis zu erstellen. Überprüfen Sie die eingecheckten generierten Artefakte, bevor Sie das Repository als Wahrheitsquelle behandeln.
Code first: Behalten Sie den API-Vertrag bei, z. B. eine OpenAPI-Beschreibung, mit der Anwendungsquelle oder dem APIOps-Repository. Definieren Sie, wer diesen Vertrag in die API-Verwaltungsartefakte transformiert, die die Pipeline veröffentlicht. Überprüfen Sie den beabsichtigten Import- und Artefaktworkflow mit einer Nichtproduktions-API-Verwaltungsinstanz. Gehen Sie nicht davon aus, dass ein beliebiges Quelllayout direkt von der CLI konsumierbar ist.
Gemeinsame Verantwortung: Legen Sie fest, ob API-Entwickler, Plattformoperatoren oder beide eigene Änderungen an Richtlinien, Produkten, Diagnosen, benannten Werten und API-Definitionen vornehmen. Nachdem der Basisplan akzeptiert wurde, leiten Sie jede Änderung durch dasselbe Repository und denselben Überprüfungsprozess weiter.

Mögliche Anwendungsfälle

Organisationen, die APIs entwickeln und verwalten, einschließlich Organisationen mit einer einzigen API, die über die API-Verwaltung verfügbar gemacht wird.
Stark regulierte Sektoren wie Versicherungen, Banken, Finanzen und Behörden, die nachverfolgbare Überprüfungs- und Bereitstellungsdatensätze benötigen.

Überlegungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, die eine Reihe von Leitsätzen sind, die Sie verwenden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Well-Architected Framework.

Reliability

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Verwenden Sie für nicht kompatibilitätsbrechende API-Änderungen API Management-Revisionen, um eine Revision, die noch nicht aktuell ist, bereitzustellen und zu testen, bevor Sie sie als aktuell festlegen. Wenn die Überprüfung nach der Veröffentlichung fehlschlägt, stellen Sie die vorherige Revision als aktuell wieder her. Verwenden Sie API-Versionen zum Unterbrechen von Vertragsänderungen, damit bestehende Verbraucher die frühere Version weiterhin verwenden können.

Koordinieren Sie Konfigurationsänderungen der API-Verwaltung mit der Bereitstellungsstrategie für jedes API-Back-End. Durch das Wiederherstellen eines APIOps-Commits wird nur die durch diesen Commit dargestellte Konfiguration wiederhergestellt. Es stellt kein inkompatibles oder nicht verfügbares Back-End wieder her. Notieren Sie den APIOps-Commit, die API-Verwaltungsrevision und das Back-End-Release, die zusammen jede als funktionsfähig bekannte Bereitstellung bilden. Testen Sie die vollständige Rollbackprozedur in einer Nichtproduktionsumgebung, einschließlich Richtlinien, benannten Werten, geheimen Verweisen, Abhängigkeiten und Back-End-Kompatibilität.

Sicherheit

Sicherheit bietet Garantien gegen bewusste Angriffe und den Missbrauch wertvoller Daten und Systeme. Weitere Informationen finden Sie in der Prüfliste zur Entwurfsüberprüfung für Sicherheit.

Verwenden Sie das Repository und die Pipeline als normalen Pfad zum Anwenden von API-Verwaltungsänderungen. Entwickler und Operatoren benötigen keinen dauerhaften Schreibzugriff auf Produktions-API-Verwaltungsinstanzen. Gewähren Sie erhöhten Zugriff nur bei Bedarf und nur für einen begrenzten Zeitraum. Stimmen Sie alle resultierenden Änderungen am Repository ab.

Verwenden Sie die folgenden Mechanismen, um das Git-Repository zu schützen, das API-Verwaltungsartefakte speichert:

Pull-Request-Überprüfung: Schützen Sie Branches, mit denen Konfigurationen bereitgestellt werden, und verlangen Sie eine Überprüfung durch die zuständigen Reviewer.
Anmeldeinformationsisolierung: Bevorzugen Sie die föderierte Workloadidentität, falls verfügbar. Speichern Sie umgebungsspezifische geheime Schlüssel in einem genehmigten geheimen Speicher oder einer Repositoryumgebung, nicht in Artefakten oder Pipelinedateien.
Commit-Integrität: Erfordert signierte Commits, um die Herkunft der Commits zu verifizieren. Konfigurieren Sie den Branchschutz so, dass Force-Pushes und das Löschen von Branches verhindert werden, verlangen Sie für Benutzer zum Genehmigen oder Zusammenführen von Änderungen eine Multifaktor-Authentifizierung, und bewahren Sie den Commit- und Pull-Request-Verlauf bei Bereitstellungen auf.
Artefaktüberprüfung: Prüfen Sie die Extraktionsausgabe und die zu veröffentlichenden Eingaben auf Geheimnisse, Schwärzungsmarkierungen und unbeabsichtigte umgebungsspezifische Werte. Überprüfen Sie, ob eine Änderung den API-Zugriff nicht erweitert oder eine Richtlinie schwächt.

Verwalten Sie die APIOps CLI als Repositoryabhängigkeit. Legen Sie @azure-tools/apiops-cli in package.json auf eine getestete Version fest, checken Sie die Sperrdatei ein und verwenden Sie npm ci. Überprüfen Sie generierte Identitätseinstellungen, Variablen, Trigger und Schutzregeln, bevor Sie eine Produktionspipeline aktivieren.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie in der Prüfliste für die Entwurfsüberprüfung für die Kostenoptimierung.

APIOps CLI ist Open-Source-Software, aber dieses Szenario verursacht Kosten für die API-Verwaltungsinstanzen und die ausgewählte Quellcodeverwaltungs- und CI/CD-Plattform. Eine einzelne feste Schätzung wird nicht bereitgestellt, da die API-Verwaltungspreise je nach Region, Ebene, Einheitenanzahl, Kapazitätsmodell, Verfügbarkeitszone oder Multiregion-Konfiguration und Nutzung variieren. CI/CD-Gebühren hängen auch vom Runner-Typ, von den enthaltenen Minuten, der Parallelität, dem Speicher und der Aufbewahrungsdauer ab.

Erstellen Sie eine szenariospezifische Schätzung im Azure Preisrechner, und notieren Sie die folgenden Annahmen mit der Architekturentscheidung:

Schätzen von Eingaben	Annahme zum Aufzeichnen
API-Verwaltungsregion	Die Bereitstellungsregion für jede Entwicklungs-, Test-, Staging- und Produktionsinstanz.
Stufe und Kapazität	Die Ebene oder v2-Ebene, die Anzahl der Einheiten oder Gateways und die Betriebsstunden für jede Umgebung.
Resiliency	Jede Bereitstellung in einer Verfügbarkeitszone oder einer zusätzlichen Region, einschließlich der Einheiten an den jeweiligen Standorten.
Nutzungsbasierte Gebühren	Erwartete Anfragen oder Operationen sowie alle anfallenden Gebühren für Arbeitsbereiche, selbstgehostete Gateways, Netzwerke, Überwachung oder Datenübertragung.
CI/CD-Plattform	GitHub-gehostete, selbstgehostete oder Azure Pipelines-Agenten. Erwartete Pipelineausführung, Dauer, Parallelität, Speicher und Protokoll- oder Artefaktaufbewahrung.
Quellcodeverwaltung und Lizenzen	Die Anzahl der Benutzer und alle kostenpflichtigen GitHub oder Azure DevOps Planfunktionen.

Verwenden Sie die aktuellen API Management-Preisdetails , um das entsprechende Abrechnungsmodell auszuwählen. Informationen zu CI/CD- und Quellcodeverwaltungsannahmen finden Sie unter Azure DevOps Preise und GitHub Preise. Exportieren oder erfassen Sie die Rechnerschätzung, ihre Währung, das Preisdatum und alle Annahmen, damit Prüfer sie reproduzieren und aktualisieren können. Vor der Bereitstellung und wenn sich Regionen, Tarifstufen, die Anzahl der Einheiten, Umgebungen oder die Pipeline-Nutzung ändern, neu berechnen.

Operative Exzellenz

„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie in der Prüfliste zur Entwurfsüberprüfung für Operational Excellence.

APIOps macht Bereitstellungen wiederholbar und erstellt einen Commit-Verlauf für die Analyse nach der Änderung. Kennzeichnen Sie den Commit, den die jeweilige Umgebung erhält, oder erfassen Sie ihn anderweitig, bewahren Sie Pipelineprotokolle auf und überwachen Sie die API-Management-Instanz sowie davon abhängige APIs nach der Bereitstellung.

Führen Sie für mehrere Umgebungen denselben überprüften Artefakt-Commit von der Entwicklungs- über die Staging- bis in die Produktionsumgebung weiter. Verwenden Sie Umgebungsüberschreibungen nur für Werte, die sich zwischen Umgebungen unterscheiden müssen, und überprüfen Sie diese Dateien mit der gleichen Sorgfalt wie die Artefakte. Untergeordnete Überschreibungen des Arbeitsbereichs werden beim Veröffentlichen nicht angewendet. Verwenden Sie sie daher nicht für die Promotion von Umgebungen. Testen Sie Rollbackprozeduren, bevor ein Vorfall auftritt. Eine Git-Wiederherstellung erfordert weiterhin eine Überprüfung und eine kontrollierte Veröffentlichung zum Wiederherstellen der API-Verwaltung.

Die CLI stellt die Befehle init, extract und publish bereit und kann Gerüste für GitHub Actions oder Azure DevOps-Pipelines erstellen. Überprüfen Sie die Befehlsdetails in der APIOps CLI-Dokumentation.

Sichere Migration aus dem legacy-APIOps-Toolkit

Wenn Ihr APIOps-Prozess das ältere APIOps-Toolkit verwendet, planen Sie das Upgrade. Bei diesem Ansatz werden separate Extraktor- und Publisher Binärdateien und Pipelinevorlagen verwendet. Die APIOps CLI verwendet ein einzelnes Node.js CLI, aber sein Artefaktformat ist so konzipiert, dass es mit vorhandenen Toolkitartefakten kompatibel ist. Behandeln Sie die Migration als kontrollierte Umschaltung, nicht als direktes Upgrade der Produktionsumgebung.

Markieren Sie die als funktionsfähig bekannten Toolkit-Artefakte und die Pipeline, und behalten Sie den vorhandenen Publisher als Rollback-Option bei. Ändern Sie den älteren Herausgeber nicht, und führen Sie den neuen Herausgeber in derselben Bereitstellung ein.
Verwenden Sie in einem Migrationszweig die neueste APIOps CLI-Version und führen Sie --force aus, ohne apiops init zu verwenden. Mit dem Befehl werden widersprüchliche Dateien erkannt und beendet, anstatt sie zu überschreiben. Vergleichen Sie die generierten Pipelines, Identitätsrichtlinien, Filter und Überschreibungsdateien und integrieren Sie sie bewusst.
Verwenden Sie die Artefakte mit apiops publish --dry-run und den Außerkraftsetzungen der Zielumgebung für eine Nichtproduktions-API-Verwaltungsinstanz. Überprüfen Sie die Ressourcen, die die CLI erstellen, aktualisieren oder löschen würde. Testen Sie eine kontrollierte Veröffentlichung und überprüfen Sie die bereitgestellten APIs, Richtlinien, benannten Werte und Abhängigkeiten.
Verwenden Sie keine untergeordneten Überschreibungen im Arbeitsbereich, die beim Veröffentlichen nicht angewendet werden, als Teil des Migrations- oder Promotionskonzepts. Validieren Sie einen alternativen Ansatz für die Höherstufung betroffener untergeordneter Ressourcen oder verschieben Sie deren Migration, bis das bekannte Problem Arbeitsbereichsbezogene Außerkraftsetzungseigenschaften werden nicht angewendet behoben ist.
Bei der Umstellung nur einem Herausgeber erlauben, in eine API Management-Instanz zu schreiben. Deaktivieren Sie den Auslöser des älteren Herausgebers, bevor Sie den CLI-Herausgeber aktivieren. Stellen Sie einen überprüften Commit bereit, und überwachen Sie das Ergebnis. Behalten Sie die markierte Toolkit-Pipeline und die Artefaktbasis bei, bis der neue Workflow einen erfolgreichen Releasezyklus abgeschlossen hat.

Kompatibilitätsdetails und Beispiele für die Migration mit Befehlen finden Sie unter "Migration von APIOps Toolkit".

Dieses Szenario bereitstellen

Folgen Sie der APIOps CLI-Dokumentation im APIOps CLI GitHub Repository. Beginnen Sie mit einer Nichtproduktions-API-Verwaltungsinstanz, und verwenden Sie den aktuellen APIOps CLI-Versionsleitfaden. Informationen zu den ersten Schritten mit einer Nichtproduktionsumgebung finden Sie unter Verwalten der API-Verwaltungskonfiguration mit APIOps CLI.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

Pat Altimore | Senior Content Developer
Wael Kdouh | Senior Principal Solution Architect
Rishabh Saha | Senior Principal Solution Architect

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Feedback

War diese Seite hilfreich?