APIs sind heutzutage nicht mehr wegzudenken. Sie haben sich zum Standard für das Verbinden von Apps, Daten und Diensten etabliert. Allgemein gesprochen bringen APIs die digitale Transformation in Organisationen maßgeblich voran.

Durch den strategischen Wert von APIs wurden auch Continuous Integration- und Continuous Deployment-Pipelines (CI/CD) zu einem wichtigen Faktor bei der API-Entwicklung. Organisationen können diese Pipelines einsetzen, um die Bereitstellung von Änderungen an einer API ohne fehleranfällige manuelle Schritte zu ermöglichen, Fehler früher zu ermitteln und Endbenutzer schneller mit entsprechenden Updates zu versorgen.

In diesem Blogbeitrag wird das Grundkonzept für die Implementierung einer CI/CD-Pipeline vorgestellt, mit der Sie Änderungen an APIs bereitstellen können, die über Azure API Management veröffentlicht wurden.

Das Problem

Heutzutage sind in Organisationen üblicherweise mehrere Bereitstellungsumgebungen (z.B. für Entwicklung, Tests und Produktion) im Einsatz, und für jede Umgebung wird eine eigene API Management-Instanz verwendet. Einige dieser Instanzen werden von mehreren Entwicklungsteams gemeinsam verwendet. Diese Teams sind jeweils für unterschiedliche APIs mit unterschiedlichen Releasezyklen zuständig.

Unsere Kunden stellen uns deshalb häufig vor folgende Herausforderungen:

• Wie kann die Bereitstellung von APIs in API Management automatisiert werden?
• Wie können Konfigurationen von einer Umgebung in eine andere migriert werden?
• Wie kann vermieden werden, dass unterschiedliche Entwicklungsteams, die die gleiche API Management-Instanz verwenden, sich beeinträchtigen?

Wir sind davon überzeugt, dass diese Herausforderungen mit dem im Folgenden ausgeführten Ansatz bewältigt werden können.

CI/CD mit API Management

Der vorgeschlagene Ansatz wird auf der obigen Abbildung veranschaulicht. In diesem Beispiel gibt es zwei Bereitstellungsumgebungen: eine für die Entwicklung und eine für die Produktion. Die Umgebungen verwenden jeweils eine eigene API Management-Instanz. Die Instanz für die Produktion wird von einem festen Team verwaltet, die als API-Herausgeber bezeichnet werden. Die API-Entwickler können nur auf die Instanz für die Entwicklung zugreifen. 

Der wichtigste Aspekt bei diesem Ansatz ist, dass alle Konfigurationen in Azure Resource Manager-Vorlagen gespeichert werden. Diese Vorlagen sollten in einem Quellcodeverwaltungssystem aufbewahrt werden. Im Beispiel verwenden wir hierfür Git. Auf der Abbildung wird ein Herausgeberrepository dargestellt, das alle Konfigurationen der API Management-Instanz für die Produktion in mehreren Vorlagen enthält:

• Dienstvorlage: Enthält alle Konfigurationen auf Dienstebene (z.B. Tarif und benutzerdefinierte Domänen).
• Gemeinsam genutzte Vorlagen: Enthält die Ressourcen, die innerhalb einer API Management-Instanz gemeinsam genutzt werden (z.B. Gruppen, Produkte und Identitätsanbieter).
• API-Vorlagen: Enthält Konfigurationen für APIs und deren untergeordnete Ressourcen (z.B. Vorgänge und Richtlinien).
• Mastervorlage: Ist mit allen Vorlagen verknüpft und somit das Bindeglied zwischen diesen.

API-Entwickler forken und klonen das Herausgeberrepository. In der Regel konzentrieren sie sich dabei auf die API-Vorlagen für ihre APIs und nehmen keine Änderungen an den gemeinsam genutzten Vorlagen oder Dienstvorlagen vor.

Die Arbeit mit Resource Manager-Vorlagen stellt API-Entwickler vor diese beiden Herausforderungen:

• Die erste besteht darin, dass API-Entwickler häufig mit OpenAPI-Spezifikationen arbeiten und nicht mit Resource Manager-Schemas vertraut sind. Wir haben deshalb ein Hilfstool entwickelt, um die Erstellung von API-Vorlagen zu vereinfachen, indem diese auf OpenAPI-Spezifikationen basierend automatisiert wird.
• Die zweite besteht für Kunden, die API Management bereits verwenden und vorhandene Konfigurationen in Resource Manager-Vorlagen extrahieren müssen. Wir haben ein weiteres Tool entwickelt, das Vorlagen anhand vorhandener Konfigurationen generiert.

Nachdem die Entwickler eine API entwickelt und getestet und die API-Vorlage generiert haben, senden Sie einen Pull Request an das Herausgeberrepository. Die API-Herausgeber können den Pull Request dann überprüfen und sich davon überzeugen, dass die Änderungen sicher und konform sind. Die meisten Überprüfungen können durch die CI/CD-Pipeline automatisiert werden. Wenn die Änderungen genehmigt und erfolgreich gemergt wurden, stellen die API-Herausgeber diese in der Instanz für die Produktion bereit. Diese Bereitstellung kann ebenfalls mit Azure Pipelines automatisiert werden.

Mit diesem Ansatz kann die Bereitstellung von API-Änderungen an API Management-Instanzen automatisiert werden, und Änderungen können einfach zwischen Umgebungen übertragen werden. Da unterschiedliche API-Entwicklungsteams an unterschiedlichen API-Vorlagen arbeiten, beeinträchtigen sich die verschiedenen Teams in der Regel nicht.

Nächste Schritte

In diesem GitHub-Repository finden Sie den Leitfaden, Beispiele und weitere Tools. Testen Sie diesen Ansatz, und wenden Sie sich mit Feedback und Fragen an uns.

Wir wissen, dass unsere Kunden unterschiedliche Entwicklungsmethoden und Automatisierungslösungen einsetzen. Bei diesem Ansatz und den zugehörigen Tools handelt es sich daher nicht um eine Universallösung. Deshalb haben wir die Komponenten als Open Source-Repository auf GitHub veröffentlicht, sodass Sie die Lösung nach Bedarf erweitern und anpassen können.