Effiziente und sichere Softwarebereitstellung mit Azure-Implementierungsumgebungen

Im März dieses Jahres hat Microsoft ein weiteres Angebot in Azure allgemein verfügbar gemacht: Azure-Bereitstellungsumgebungen. Mit Azure Deployment Environments können Entwicklungsteams schnell und einfach eine App-Infrastruktur aufsetzen. Diese Infrastruktur wird in projektbasierten Vorlagen definiert, die für Konsistenz und bewährte Verfahren sorgen und gleichzeitig die Sicherheit maximieren. Die Infrastruktur kann z. B. vom Plattformteam geschrieben werden. Ein Entwicklungsteam kann dann bei Bedarf sichere Umgebungen über ein Self-Service-Erlebnis erstellen, das alle Phasen des Softwareentwicklungszyklus beschleunigt. Azure Deployment Environments sind Teil des Azure Dev Centers, in dem auch die Azure Dev Boxes untergebracht sind.

Wenn Sie sich gleich die Hände schmutzig machen wollen, dann nutzen Sie dieses tolle Tutorial auf Microsoft Learn. Möchten Sie etwas mehr über den Dienst erfahren, bevor Sie ihn nutzen? Lesen Sie weiter! Bevor wir uns näher mit Azure Deployment Environments befassen, lassen Sie uns zunächst einen Blick auf die Probleme werfen, die der Dienst zu lösen versucht.

Ein zentraler Ansatz für die Verwaltung der Cloud

Moderne Cloud-native Anwendungen nutzen eine Vielzahl verschiedener Dienste in der Cloud. Die Verwaltung dieser Infrastruktur kann eine Herausforderung sein, da sie schnell komplex wird. Um sichere und konforme Umgebungen zu schaffen, muss man viel über Skalierung, Identität, Netzwerke und Kosten wissen. Häufig sind Entwickler keine Experten in diesen Bereichen und, was vielleicht noch wichtiger ist, sie wollen es auch gar nicht sein. Sie wollen die Logik schreiben, die dem Unternehmen einen Nutzen bringt, und nicht die Infrastruktur aufbauen. Das bedeutet, dass das erforderliche Wissen zum Aufbau der Infrastruktur in jedem DevOps-Team nicht vorhanden ist.

Fehlendes Wissen ist einer der Gründe, warum Unternehmen dazu neigen, ein zentrales Team mit der Kontrolle über ihre Cloud zu betrauen. Ressourcen werden über ein zentrales IT-Team angefordert. Aufgrund überragender Sicherheits- und Compliance-Bedenken verweigern Unternehmen in der Regel den direkten Zugriff von Entwicklern auf öffentliche Cloud-Plattformen wie Azure. Viele Unternehmen haben mit sensiblen Daten zu tun, z.B. mit persönlichen Informationen oder geschützten Geschäftsdaten, was strenge Sicherheitsmaßnahmen erforderlich macht. Wenn Sie Entwicklern ungehinderten Zugang zu öffentlichen Cloud-Diensten gewähren, könnten Sie versehentlich kritische Daten preisgeben oder die Einhaltung von Branchenvorschriften verletzen. Bei diesem Ansatz stehen der Schutz sensibler Daten und die Einhaltung etablierter Sicherheitsstandards im Vordergrund.

Die dynamische und skalierbare Natur von Public Cloud Services rückt die Herausforderung des Kostenmanagements in den Vordergrund. Unternehmen verwenden ein zentralisiertes Modell für die Zuweisung von Cloud-Ressourcen, um potenzielle finanzielle Risiken zu minimieren. Öffentliche Cloud-Plattformen werden auf einer Pay-as-you-go-Basis betrieben, so dass eine Kontrolle der Ressourcenbereitstellung unabdingbar ist. Unternehmen neigen zu der Ansicht, dass ein zentrales Team besser in der Lage ist, die Ressourcennutzung zu überwachen, zu verfolgen und zu optimieren und so unvorhergesehene Kosten zu vermeiden, die durch nicht verwaltete oder unnötige Ressourcen entstehen. Sie glauben, dass dieser Ansatz zu einer besser vorhersehbaren und kontrollierten Finanzlandschaft beiträgt.

Ein weiterer Grund für diesen zentralen Ansatz ist, dass die zentrale Kontrolle über die Bereitstellung von Ressourcen in der öffentlichen Cloud zu einer besseren Ressourcenzuweisung und -nutzung führt. Ohne diese Vogelperspektive könnten Entwickler unabhängig voneinander redundante oder unzureichend genutzte Ressourcen erstellen, was zu Ineffizienzen und verschwendeter Kapazität führt. Ein zentrales Team kann den gesamten Ressourcenbedarf des Unternehmens bewerten, die Abstimmung mit den Geschäftszielen sicherstellen und die Ressourcen so zuweisen, dass die Effizienz maximiert und Redundanzen minimiert werden. Dadurch werden Ressourcen geschont und eine effektivere Nutzung der Cloud-Infrastruktur gefördert.

Eine grundlegende Herausforderung in großen Unternehmen ist die Aufrechterhaltung der Konsistenz und Zusammenarbeit zwischen verschiedenen Projekten und Entwicklungsteams. Ein zentraler, vom Team verwalteter Ansatz fördert die Standardisierung und Zusammenarbeit, indem er einheitliche Praktiken, Vorlagen und Konfigurationen für Cloud-Ressourcen festlegt. Dadurch wird sichergestellt, dass alle Projekte die etablierten Best Practices und Konfigurationen einhalten, wodurch das Risiko von Sicherheitsschwachstellen oder betrieblichen Diskrepanzen aufgrund von Fehlkonfigurationen verringert wird. Dieser Ansatz kann die Entwicklungsarbeit rationalisieren, die teamübergreifende Zusammenarbeit erleichtern und zu qualitativ hochwertigeren Ergebnissen beitragen.

Warum ist dieser zentrale Ansatz ein Problem?

Dieser zentrale Ansatz für die Verwaltung der Cloud-Umgebung mag zwar auf den ersten Blick vernünftig erscheinen, da er kritische Aspekte des Unternehmensbetriebs zu schützen scheint, aber er bringt auch Herausforderungen mit sich. Herausforderungen, die Azure Deployment Environment für Sie zu lösen versucht. Einer der auffälligsten Nachteile ist das Potenzial für eine langsamere Ressourcenzuweisung und Flexibilität. Dieses Modell zwingt die Entwickler dazu, darauf zu warten, dass das zentrale Team die erforderlichen Cloud-Ressourcen zuweist. Dies führt zu Verzögerungen in den Projektzeitplänen und behindert die Agilität und Reaktionsfähigkeit, die in der heutigen schnelllebigen Entwicklungslandschaft erforderlich sind. Wenn ein zentrales Team als Gatekeeper für die gesamte Ressourcenbereitstellung fungiert, besteht die Gefahr, dass es in Spitzenzeiten zu einem Engpass kommt. Missverständnisse oder mangelndes Verständnis zwischen Entwicklern und dem zentralen Team können zu einer unausgewogenen Ressourcenzuweisung führen, so dass Projekten zu wenig oder zu viele Ressourcen zugewiesen werden.

Wie können Azure-Bereitstellungsumgebungen helfen?

Für die effektive Verwaltung von Public Cloud-Ressourcen in Unternehmensumgebungen ist es nach wie vor entscheidend, ein Gleichgewicht zwischen zentraler Kontrolle und Eigenverantwortung der Entwickler zu finden. Azure Deployment Environments ist ein neuer Service, der diese Herausforderungen angeht, indem er Entwicklern eine Self-Service-Umgebung auf Abruf zur Verfügung stellt. Über ein Entwicklerportal, die Azure CLI oder CI/CD-Pipelines können Sie Umgebungen erstellen, löschen oder neu bereitstellen. So können Entwickler ihre Umgebungen bereitstellen, wenn sie sie brauchen. In Zukunft wird das Produkt um eine neue Funktion erweitert, mit der Sie ein Verfallsdatum für eine Umgebung festlegen können. Eine Umgebung wird dann automatisch gelöscht, wenn sie abläuft, um zu verhindern, dass die Umgebung Geld verbrennt, während sie nicht mehr verwendet wird. Eine weitere Option, die wir in Zukunft hinzufügen werden, wird es uns ermöglichen, die Umgebung automatisch zu verkleinern, z. B. am Wochenende. Diese Funktionen werden Ihnen helfen, die Kosten zu kontrollieren.

Azure Deployment Environments können auch die oft redundante Arbeit eines zentralen Plattformteams reduzieren. Es ermöglicht die Konfiguration einer integrierten Governance und eine zentrale Kontrolle über die Umgebungen. Der Plattformingenieur würde zunächst ein Dev Center und ein Projekt erstellen. Ein einzelnes Projekt steht in der Regel für ein einzelnes Entwicklungsteam. Plattform-Ingenieure können dann die verschiedenen Arten von Umgebungen definieren, die ein bestimmtes Projekt nutzen kann. Für einen bestimmten Umgebungstyp können sie festlegen, wer diesen Typ von Umgebung erstellen darf. So kann ein Entwicklungsteam beispielsweise nur eine Entwicklungs- oder Testumgebung erstellen. Ein Qualitätsingenieur könnte berechtigt sein, die Testumgebungen zu erstellen. Schließlich kann eine CI/CD-Pipeline so konfiguriert werden, dass sie eine Staging- und eine Produktionsumgebung erstellt.

Umgebungen werden in Vorlagen definiert, wobei Infrastruktur als Code verwendet wird. Dies ermöglicht eine zentrale Kontrolle über die Ressourcenzuweisung und -verwaltung, z. B. durch ein Plattformteam. Ein Git-Repository kann als Katalog an den Dienst angehängt werden. Der Dienst durchsucht dieses Repository automatisch, identifiziert diese Infrastruktur-als-Code-Vorlagen und stellt sie den Entwicklern zur Verfügung. Dabei werden sie aufgefordert, einige grundlegende Informationen über die Umgebung anzugeben. Sie werden z.B. nicht nach dem Abonnement, der Ressourcengruppe oder anderen Azure Governance-bezogenen Aspekten der Umgebung gefragt.

Diese Informationen wurden bereits vom Plattformingenieur in Azure Deployment Environments konfiguriert, was die Bereitstellung der Umgebungen erleichtert. Das bedeutet auch, dass alle Richtlinien, die für die Abonnements oder eine höhere Verwaltungsgruppe gelten, automatisch in jeder neuen Umgebung durchgesetzt werden. Dies trägt dazu bei, dass alle Umgebungen konform sind. Plattformingenieure können auch die Identitäten konfigurieren, die für die Erstellung der Umgebung verwendet werden sollen. Wenn ein Entwickler eine Umgebung erstellen möchte, verwendet der Dienst verwaltete Identitäten, um die Bereitstellung im Namen des Benutzers durchzuführen. Dies ist sicherer und isolierter, da diese verwalteten Identitäten speziell für diesen Umgebungstyp und für dieses Entwicklerteam gelten. Ein Plattformingenieur kann außerdem konfigurieren, welche Berechtigungen den Entwicklern bei der Erstellung der Umgebung zugewiesen werden sollen. Die Möglichkeit, Berechtigungen so granular festzulegen, passt gut in eine Zero-Trust-Architektur. Schließlich können Tags automatisch auf alle Ressourcen angewendet werden, die von den Entwicklern erstellt werden. Auf diese Weise können Sie weiterhin andere Tools verwenden, die Sie beispielsweise zur Verfolgung und Verwaltung der Kosten der Ressourcen in Azure einsetzen.

Wir haben jetzt gesehen, wie Azure Deployment Environment versucht, sowohl den Entwicklern als auch den Plattformingenieuren zu helfen. Jetzt, da wir mehr über das Produkt wissen und wie es beiden Rollen bei ihrer Arbeit helfen kann, sehen wir es uns in Aktion an!

Wie würde ich Azure Deployment Environments als Platform Engineer nutzen?

Wie in der Einführung erwähnt, sind Azure Deployment Environments Teil des Azure Dev Centers. Dieser Dienst beherbergt auch die Azure Dev Boxes. Azure Dev Boxes sind vorkonfigurierte Entwicklungsumgebungen, die Entwickler nutzen können, um schnell mit der Entwicklung von Anwendungen zu beginnen. In diesem Artikel werden wir nicht näher auf Azure Dev Boxes eingehen, aber Sie können hier mehr über sie lesen.

Nachdem Sie ein Dev Center erstellt haben, müssen Sie vier Elemente konfigurieren, um mit den Bereitstellungsumgebungen zu beginnen: - Ein Projekt - Umgebungstypen - Ein Vorlagenkatalog - Eine Identität

Ein Projekt erstellen

Mit Projekten können Sie Umgebungen und Dev Boxen auf Teamebene verwalten. Die Erstellung eines Projekts ist sehr einfach. Für die Grundkonfiguration benötigen Sie einen Namen und die Ressourcengruppe, in der das Projekt bereitgestellt werden soll.

Umgebungstypen erstellen

Umgebungstypen helfen dabei, die Umgebungen zu definieren, die Entwicklungsteams erstellen können. Diese werden später in einem Projekt referenziert, und Sie können dann für jeden Typ eindeutige Bereitstellungseinstellungen festlegen. Beispiele hierfür könnten Entwicklung, Test und Produktion sein. Für die Erstellung eines Umgebungstyps auf der Ebene des Dev Centers ist lediglich ein Name erforderlich und Sie können Standard-Tags hinzufügen. Diese Tags werden zu allen Ressourcen hinzugefügt, die in einer Umgebung dieses Typs erstellt werden. Wir werden gleich sehen, was wir mit diesen Umgebungstypen in einem Projekt tun können.

Konfigurieren der Identität

Als nächstes muss die Identität konfiguriert werden. Diese Identität wird für die Bereitstellung der Umgebungen verwendet und muss über die entsprechenden Berechtigungen verfügen. Die Identität kann eine verwaltete Identität oder ein Dienstprinzipal sein. Wir werden später noch sehen, dass ein granularer Ansatz möglich ist, bei dem Sie verschiedene Identitäten für verschiedene Projekte und verschiedene Umgebungstypen konfigurieren können.

Einen Vorlagenkatalog erstellen

Bei der Bereitstellung einer Umgebung wird diese mithilfe einer Vorlagendefinition erstellt. Eine Vorlagendefinition ist ein Satz von Terraform- (in der Vorschau) oder ARM-Dateien, die die zu implementierende Infrastruktur definieren. Ein Vorlagenkatalog ist eine Sammlung dieser Vorlagendefinitionen. Ein Vorlagenkatalog kann auf der Ebene des Dev Centers erstellt werden und von einem Projekt aus referenziert werden. So haben Sie einen zentralen Ort, an dem Sie alle Ihre Vorlagendefinitionen verwalten können. Die folgende Abbildung zeigt Ihnen, wie Sie einen neuen Vorlagenkatalog erstellen.

Ein Vorlagenkatalog ist ein Verweis auf ein GIT-Repository, das die Vorlagen enthält. Wie Sie in der Abbildung sehen können, können Sie die URI, die Verzweigung und den Pfad innerhalb des Repos angeben, in dem Ihre Definitionen gespeichert sind. Ein PAT wird für den Zugriff auf das GIT-Repository verwendet und muss in einem Key Vault gespeichert werden. Die im Dev Center konfigurierte Identität benötigt Zugriff auf diesen Key Vault. Wir werden gleich sehen, wie Sie eine Vorlagendefinition erstellen.

Nachdem wir nun das Dev Center konfiguriert haben, können wir mit der Konfiguration des neuen Projekts beginnen, das wir gerade erstellt haben.

Das Projekt konfigurieren

Erinnern Sie sich, dass wir vorhin über Umgebungstypen gesprochen haben? Jetzt können wir diese Umgebungstypen verwenden, um das Projekt zu konfigurieren. Das folgende Bild zeigt die Erstellung eines neuen Umgebungstyps im Projekt.

Im Feld Typ können wir alle Typen auswählen, die auf der Ebene des Dev Centers erstellt und noch nicht verwendet wurden. Als nächstes können wir das Abonnement auswählen, das für die Bereitstellung der Umgebung verwendet wird. In diesem Beispiel verwende ich nur ein Abonnement für mehrere Umgebungstypen. In einem realen Szenario wäre es ratsam, für jedes Team ein separates Abonnement für Test- und Produktions-Workloads zu haben.

Als nächstes können wir einige Optionen rund um Identitäten und Berechtigungen konfigurieren. Zunächst können wir die Identität auswählen, die für die Bereitstellung von Umgebungen dieses Typs verwendet wird. So können Sie verschiedene Identitäten für verschiedene Umgebungstypen verwenden und sicherstellen, dass es nie eine einzige Identität mit Zugriff auf alle Umgebungen gibt. Dann können wir die Berechtigungen, die neuen Umgebungen dieses Typs zugewiesen werden, für denjenigen konfigurieren, der sie erstellt. Wenn Sie eine Umgebung über die Azure CLI erstellen, werden Ihnen die Berechtigungen zugewiesen. Wenn Sie die Umgebung in einer CI/CD-Pipeline erstellen, erhält die Identität, die die Pipeline ausführt, die Berechtigungen. Unterhalb dieser Option können Sie zusätzliche Benutzer oder Gruppen angeben, die bestimmte Berechtigungen für die neu erstellte Umgebung benötigen. So können Sie beispielsweise einem Team Leserechte zuweisen, wenn es diese Rechte nicht bereits auf der Abonnementebene hat.

Die folgende Abbildung zeigt die Berechtigungen, die bei der Erstellung einer neuen Umgebung mit den im Bild oben gezeigten Einstellungen festgelegt werden.

Wir können sehen, dass 'my-project-Test', mein GitHub Actions-Benutzer für diesen Umgebungstyp, die Rolle Contributor zugewiesen wurde. Die Identität 'my-project/environmentTypes/Test', die vom System zugewiesene verwaltete Identität für diesen speziellen Umgebungstyp, erhält die Berechtigung Owner.

Die letzte Konfiguration, die Sie für ein Projekt vornehmen möchten, ist die, wer es benutzen darf. Derjenige, der das Projekt erstellt hat, ist automatisch ein Administrator und hat die Rolle 'DevCenter Project Admin' zugewiesen bekommen. Darüber hinaus können Sie dem Team, das zu diesem Projekt gehört, die Rolle 'Deployment Environments User' zuweisen. Diese können dann die Umgebungen, die zu diesem Projekt gehören, erstellen und verwenden.

Nachdem wir nun das Entwicklungszentrum und das Projekt konfiguriert haben, ist es an der Zeit, eine Vorlagendefinition zu erstellen, die wir bereitstellen können!

Erstellen einer Vorlagendefinition

Das folgende Bild zeigt den Ordner 'Environments', der bei der Konfiguration des Katalogs im Entwicklungszentrum verwendet wird. Die Ordnerstruktur ist wichtig, da sie bestimmt, welche Vorlagendefinitionen bei der Erstellung einer neuen Umgebung verfügbar sind. Jeder Ordner steht hier für eine einzelne Vorlage.

Jede Vorlagendefinition muss eine manifest.yaml haben. Diese manifest.yaml Datei enthält die Metadaten für die Vorlagendefinition. Diese Informationen werden z.B. verwendet, um die Benutzeroberfläche zu füllen, wie wir später bei der Erstellung einer Umgebung sehen werden. Hier ist die manifest.yaml für die Vorlagendefinition 'FunctionApp'.

name: FunctionApp
version: 1.0.0
summary: Azure Function App Environment
description: Deploys an Azure Function App, Storage Account, and Application Insights
runner: ARM
templatePath: azuredeploy.json
parameters:
 - id: name
 name: Name
 description: 'Name of the Function App.'
 type: string
 required: true
 - id: supportsHttpsTrafficOnly
 name: 'Supports Https Traffic Only'
 description: 'Allows HTTPS traffic only to Storage Account and Functions App if set to true.'
 type: boolean
 - id: runtime
 name: Runtime
 description: 'The language worker runtime to load in the function app.'
 type: string
 allowed:
 - node
 - dotnet
 - java
 default: dotnet

Diese Datei enthält zunächst Standardfelder wie einen Namen, eine Version und eine Beschreibung. Der Läufer gibt an, ob Ihre Vorlagen mit ARM oder Terraform geschrieben werden. Die Verwendung von Terraform ist zum Zeitpunkt des Schreibens dieses Artikels noch in der Vorschau, aber Sie können sich für die Verwendung anmelden. In diesem Beispiel wird eine ARM-Vorlage und damit der Runner verwendet: ARM. Der templatePath verweist auf die ARM-Vorlage, die für die Bereitstellung der Umgebung verwendet wird. Bicep wird nicht unterstützt, aber da es der Nachfolger von ARM-Vorlagen ist, wird es der Verwendung einer ARM-Vorlage vorgezogen. Glücklicherweise können Sie Bicep verwenden und es in eine ARM-Vorlage transpilieren, wie es in diesem Beispiel gemacht wird. Die 'main.bicep' enthält alle erforderlichen Ressourcen, damit die Funktions-App funktioniert, und kann dann mit dem folgenden Befehl in 'azuredeploy.json' umgewandelt werden:

az bicep build --file main.bicep --outfile azuredeploy.json

Der Abschnitt Parameter definiert die Parameter, die für die Bereitstellung der Vorlage erforderlich sind. Diese Parameter werden verwendet, um das Formular bei der Erstellung einer neuen Umgebung auszufüllen.

Damit können wir jetzt eine neue Umgebung schaffen!

Wie verwende ich Azure Deployment Environments als Entwickler?

Es gibt mehrere Möglichkeiten, wie ein Entwickler Bereitstellungsumgebungen nutzen kann. Die erste davon ist die manuelle Bereitstellung einer neuen Umgebung. Dies geschieht über das Entwicklungsportal oder ein Entwicklungstool wie Azure CLI. Die andere Möglichkeit ist die Verwendung Ihrer CI/CD-Pipeline zur Bereitstellung einer neuen Umgebung.

Manuelles Bereitstellen einer neuen Umgebung

Lassen Sie uns zunächst einen Blick auf das Dev Portal werfen. Das Dev Portal ist ein webbasiertes Portal, das zur Verwaltung von Azure Deployment Environments verwendet werden kann. Sie finden es unter devportal.microsoft.com. Es bietet einen Überblick über alle derzeit bereitgestellten Umgebungen und ermöglicht einem Entwickler die Bereitstellung einer neuen Umgebung. Die genauen Schritte zur Erstellung einer neuen Umgebung hängen davon ab, ob Sie auch Zugriff auf Dev Boxes haben. Wenn dies nicht der Fall ist, sehen Sie in der oberen linken Ecke eine blaue Schaltfläche mit der Aufschrift 'Neue Umgebung'. Wenn Sie Zugang zu Dev Boxes haben, ist diese Schaltfläche ein Dropdown-Menü und eine der beiden Optionen lautet "Neue Umgebung". Wenn Sie auf die Schaltfläche 'Neue Umgebung' klicken, wird Ihnen das folgende Formular angezeigt:

Hier müssen Sie einen Namen für die neue Umgebung eingeben, den Umgebungstyp wie 'Dev' auswählen und die Vorlagendefinition auswählen. Wir werden später darüber sprechen, wie diese Vorlagendefinitionen erstellt werden. Nachdem Sie auf Weiter geklickt haben, müssen Sie einige zusätzliche Parameter eingeben, die für diese spezielle Vorlagendefinition erforderlich sind. Sobald das Formular übermittelt wurde, wird die Umgebung bereitgestellt. Dies kann ein paar Minuten dauern. Sobald die Umgebung bereitgestellt ist, wird sie in der Umgebungsliste angezeigt.

Die gleiche Umgebung kann auch mit der Azure CLI erstellt werden. Der Azure CLI-Befehl lautet az devcenter dev environment create. Der folgende Befehl erstellt eine neue Umgebung namens 'my-dev-environment' unter Verwendung der Vorlagendefinition 'my-template-definition'. Sie müssen auch angeben, in welchem Projekt und Entwicklungszentrum die Umgebung erstellt werden soll. Der Katalogname ist der Name des Katalogs, der die Vorlagendefinition enthält.

az devcenter dev environment create 
              --name 'my-dev-environment' --environment-type 'Dev' 
              --dev-center ${{ vars.AZURE_DEVCENTER }} --project ${{ vars.AZURE_PROJECT }} 
              --catalog-name ${{ vars.AZURE_CATALOG }} --environment-definition-name 'my-template-definition'

Bereitstellen einer neuen Umgebung mit CI/CD

Eine weitere interessante Verwendung der Azure Deployment Environments ist der Einsatz in Ihrer CI/CD-Pipeline. So können Sie für jede Verzweigung oder jeden Pull Request, der erstellt wird, eine neue Umgebung erstellen. Für Sie als derjenige, der die Verzweigung oder den PR erstellt hat, bedeutet dies, dass Sie Ihren Pull Request in einer echten, vollständig isolierten Umgebung testen können. Diejenigen, die Ihren PR überprüfen oder testen müssen, können dies tun, ohne selbst etwas bereitstellen zu müssen.

In der obigen Abbildung sehen wir, dass in der Zusammenfassung einer GitHub-Aktion ein Link zu der bereitgestellten Umgebung in Azure und ein Link zu der bereitgestellten API auf der Azure-Funktion angezeigt werden. Die gleichen Informationen können auch als Kommentar zum PR hinzugefügt werden, wie unten gezeigt.

Dies ermöglicht es dem Prüfer, die API zu testen und zu sehen, ob die Änderungen wie erwartet funktionieren.

Kurz gesagt, sind dies die Schritte in der GitHub-Aktion: - Erstellen Sie eine .NET Core API (eine sehr einfache API mit einem einzigen Endpunkt, der Zeitzoneninformationen zurückgibt) - Melden Sie sich mit der Azure CLI bei Azure an - Erstellen Sie die Umgebung mit der Azure CLI - Stellen Sie die API mit der Azure CLI in der Umgebung bereit - Fügen Sie dem PR einen Kommentar mit dem Link zur bereitgestellten API und Umgebung hinzu

Diese Beispiele für GitHub-Aktionen finden Sie in einem von Microsoft freigegebenen Repository, wie es in dem in der Einleitung erwähnten Tutorial verwendet wird. Meine leicht veränderte Version finden Sie hier.

Sie bauen es, Sie betreiben es?

Microsoft nennt einen der Vorteile dieses neuen Tools: Plattformteams können die Infrastruktur verwalten, indem sie die Vorlagendefinitionen erstellen. Die Teams können dann die Self-Service-Funktionen der Tools nutzen, um sie zu verwenden. Aus Sicht der Compliance und der Governance sollte dies Vorteile bringen, da dieses zentrale Team z. B. Sicherheitsrichtlinien durchsetzen kann. Aber wie wir bereits erwähnt haben, führt ein solcher zentraler Ansatz oft dazu, dass ein einzelnes Team der Engpass für andere ist. Was ist aus dem Motto 'Sie bauen es, Sie betreiben es' geworden?

Ich liebe es, in DevOps-Teams zu arbeiten, die von Anfang bis Ende für ihr Produkt verantwortlich sind. Dazu gehört für mich auch die Bereitstellung der Infrastruktur. Ich habe gelernt, dass es in unserer Branche keine Einheitsgröße für alle gibt. Unternehmen und Teams sind manchmal einfach noch nicht bereit für diese Art der Arbeit. Die Teams sind vielleicht nicht funktionsübergreifend genug und haben niemanden, der genug Wissen hat, um die Infrastruktur zu verwalten. In anderen Fällen sehe ich Cloud-Implementierungen, die nicht ausgereift genug sind, um sich den Entwicklungsteams zu öffnen und die Einhaltung von Vorschriften und Sicherheit zu gewährleisten. Für diese Unternehmen bringt dieses Tool viele Vorteile mit sich, da es zumindest eine Menge Selbstbedienungsoptionen bietet. Reifere Teams können die Vorlagendefinitionen nutzen, die in der Versionskontrolle gespeichert sind und leicht gemeinsam genutzt werden können. Auf diese Weise kann die Zusammenarbeit durch inneres Sourcing gefördert werden. Teams können kleine Änderungen an Vorlagen vornehmen und eine Pull-Anfrage erstellen. Ein Mitglied des Plattformteams kann immer noch der Eigentümer des Codes sein und muss die Änderung genehmigen. Da ein Dev Center mehrere Kataloge verwenden kann, können ausgereifte Teams ihr eigenes GIT-Repository verwenden und es verlinken. Die Nutzung des Produkts und seine Arbeitsweise können also mit der Reife der Ingenieure und des Unternehmens wachsen.