Anwenden von Softwareentwicklungssystemen

Sobald Sie die Probleme verstanden haben, die Sie zuerst in Ihrer Plattformentwicklung angehen möchten, kann die Verbesserung des Entwickler-Self-Service ganz oben auf der Liste stehen. Eine der einfachsten Möglichkeiten, automatisierte Self-Service-Erfahrungen zu ermöglichen, besteht darin, Ihre vorhandenen Technischen Systeme wiederzuverwenden. Diese Systeme sind nicht nur Ihnen und Ihren internen Kunden vertraut, sondern sie können auch eine breite Palette von Automatisierungsszenarien ermöglichen, auch wenn die anfängliche Benutzererfahrung nicht schön ist.

In diesem Artikel finden Sie einige Tipps zum Anwenden Ihrer Technischen Systeme, um eine breitere Palette von Self-Service-Szenarien zu bewältigen, und wie Sie bewährte Methoden in Vorlagen kapseln können, die Ihnen helfen, richtig zu beginnen und richtig zu bleiben.

Auswerten Ihrer DevOps- und DevSecOps-Basispraktiken

Engineering-Systeme sind ein wichtiger Aspekt Ihrer internen Entwicklerplattform. Wenn Sie jedoch über keine Systeme verfügen, die mindestens auf einige der Standard Mandanten von DevOps und DevSecOps abzielen, werden Die von Ihnen identifizierten Probleme wahrscheinlich dazu führen, dass Sie dort beginnen sollten. Daraus werden interne Entwicklerplattformen aufgebaut, um die kognitive Last für alle Beteiligten zu verringern.

Zur Zusammenfassung kombiniert DevOps Entwicklung und Vorgänge, um Personen, Prozesse und Technologien bei der Anwendungsplanung, -entwicklung, -bereitstellung und -betrieb zu vereinen. Es soll die Zusammenarbeit in historisch isolierten Rollen wie Entwicklung, IT-Betrieb, Qualitätsentwicklung und Sicherheit verbessern. Sie richten eine kontinuierliche Schleife zwischen Entwicklung, Bereitstellung, Überwachung, Beobachtung und Feedback ein. DevSecOps-Ebenen in dieser Schleife mit kontinuierlichen Sicherheitspraktiken während des gesamten Anwendungsentwicklungsprozesses.

Das DevOps-Ressourcencenter von Microsoft ist ein hervorragender Ort, um Ratschläge zu den Typen von Prozessen und Systemen zu erhalten, die Sie benötigen. Daher werden wir diese in diesem Abschnitt nicht ausführlich behandeln. Diese werden zu wichtigen Zutaten, wenn Sie voranschreiten. Vergessen Sie nicht, die neuesten DevSecOps-Themen wie Die Sicherheit der Container-Lieferkette in Ihre Pläne einzuordnen.

Weitere Informationen zum kontinuierlichen Feedback finden Sie unter Zu berücksichtigende Metriken. Weitere Informationen zu Tools für die Verwendung in den Bereichen Beobachtbarkeit, Überwachung und kontinuierliches Feedback finden Sie auch unter Verfeinern Ihrer Anwendungsplattform.

Im weiteren Verlauf dieses Artikels konzentrieren wir uns auf Verbesserungen, die direkter auf die Plattformentwicklung zurückzuführen sind: gepflasterte Pfade, automatisierte Infrastrukturbereitstellung (zusätzlich zur Anwendungsbereitstellung), Einrichtung der Programmierumgebung sowie Self-Service-Bereitstellung und Konfiguration von Tools, Teamressourcen und Diensten, die nicht direkt Teil der Anwendungsentwicklungsschleife sind.

Einrichten der gewünschten gepflasterten Pfade

Wenn Sie bereits über mehrere Tools verfügen, aus denen Ihre Engineeringsysteme bestehen, müssen Sie frühzeitig entscheiden, ob Sie diese im Rahmen Ihrer ersten Plattformentwicklungsbemühungen erfolgreich konsolidieren möchten oder ob Sie eine Konstellation verschiedener Tools von Anfang an unterstützen. In den meisten Fällen ist das Definieren einer Reihe von gepflasterten Pfaden innerhalb dieser Konstellation von Tools am effektivsten und bietet ein höheres Maß an Flexibilität.

Wenn Sie beginnen, sich zu einer Produktmentalität zu entwickeln, können Sie sich die Engineering-Systeme innerhalb dieser gepflasterten Pfade als Tools vorstellen, die zentral als Service für Entwicklungsteams verwaltet werden. Einzelne Teams oder Abteilungen innerhalb Ihres organization können dann abweichen, es wird jedoch erwartet, dass sie ihre Tools separat verwalten, verwalten und bezahlen, während sie alle Complianceanforderungen einhalten. Dies bietet eine Möglichkeit, neue Tools ohne Unterbrechungen in das Ökosystem einzuspeisen, da Sie alles bewerten können, was für eine mögliche Einbeziehung in einen gepflasterten Pfad im Laufe der Zeit abweicht. Wie ein Plattformentwicklungsleiter es ausdrückte:

Sie können immer noch Ihr eigenes Ding tun, aber in eine Richtung, die wir gehen... Sie können ändern, was Sie wollen, aber dies wird zu Ihrer Verantwortung. Sie besitzen die Veränderungen – Sie besitzen die scharfen Messer. - Mark, platform engineering lead, Large European Multinational Retail Company

Angesichts der Tatsache, dass ein zentrales Ziel für das Plattform-Engineering darin besteht, zur Produktmentalität zu wechseln, in der Sie Ihren internen Kunden einen Mehrwert bieten, funktioniert dieser Konstellationsansatz in der Regel besser als ein Mandat von oben nach unten. Wenn Sie Ihre gepflasterten Pfade einrichten und verfeinern, können Teams durch eine gewisse Flexibilität Eingaben bereitstellen und alle wirklich einzigartigen Anforderungen für eine bestimmte Anwendung erfüllen, ohne andere in der organization. Dies führt zu einer Reihe von vollständig gepflasterten, goldenen Pfaden, während andere nur teilweise gepflastert sind. In Fällen, in denen es keine eindeutigen Anforderungen gibt, führt die zusätzliche Arbeit von Entwicklungsteams natürlich dazu, dass sie im Laufe der Zeit zu einem unterstützten Pfad wechseln möchten.

Wenn Sie eine Konsolidierungsstrategie bevorzugen, denken Sie daran, dass die Migration vorhandener Anwendungen möglicherweise mehr Arbeit als erwartet ist. Daher sollten Sie sich zunächst wahrscheinlich auf den richtigen Startaspekt dieses Bereichs konzentrieren und sich auf neue Projekte konzentrieren. Dies gibt Ihnen Ihren ersten gepflasterten Weg, während alles Vorhandene von Natur aus unbefestigt ist. Entwicklungsteams auf dem unbefestigten Pfad ziehen dann eine Verschiebung in Betracht, sobald ihr neuer gepflasterter Pfad seinen Wert für den organization anzeigt. An diesem Punkt können Sie eine get right-Kampagne ausführen, um alle auf Ihren gewünschten Zustand durch bidirektionale Kommunikation zu bringen, da Entwicklerteams dies als Vorteil und nicht als Steuer betrachten. Während der Kampagne können sich Plattformentwicklungsteams darauf konzentrieren, Teams bei der Migration zu unterstützen, während die Entwicklerteams Feedback geben, wie die gepflasterten Pfade verbessert werden können.

Versuchen Sie trotzdem, die Verwendung Ihrer gepflasterten Pfade zu vermeiden. Der effektivste Weg, sie auszurollen, besteht darin, herauszubekommen, welche Teams aus ihnen herausbekommen, anstatt durch erzwungene Einführung. Da sich Ihre interne Entwicklerplattform darauf konzentriert, genau diese Teams glücklich zu machen, neigen Budget- und Zeitdruck auf einzelne Führungskräfte dazu, den Rest zu erledigen. Holen Sie sich die richtigen Kampagnen, und bieten Sie eine Möglichkeit für bidirektionale Unterhaltungen auf der besten Weise für diejenigen, die sich auf einem unbefestigten Weg befinden, um zu wechseln.

Verwenden von Tools zur Entwicklerautomatisierung zum Verbessern des Self-Service für Ihre gepflasterten Pfade

Ein Teil der Erstellung Ihres ersten gepflasterten Pfads sollte die Einrichtung Ihrer wichtigsten Entwicklerautomatisierungsprodukte sein. Diese sind wichtig, wenn Sie über die Aktivierung von Self-Service-Funktionen für Entwickler nachdenken.

Aktivieren der automatischen Bereitstellung der Anwendungsinfrastruktur während der Continuous Delivery

Wenn sie noch nicht implementiert sind, weisen die Probleme, die Sie während der Planung identifiziert haben, wahrscheinlich auf Probleme hin, die durch Continuous Integration (CI) und Continuous Delivery (CD) behoben werden können. In diesem Bereich gibt es Produkte wie GitHub Actions, Azure DevOps, Jenkins sowie Pull-basierte GitOps-Lösungen wie Flux oder Argo CD. Die ersten Schritte zu diesen Themen finden Sie im Microsoft DevOps-Ressourcencenter.

Auch wenn Sie bereits eine Möglichkeit zum kontinuierlichen Bereitstellen Ihrer Anwendung in der vorhandenen Infrastruktur implementiert haben, sollten Sie auch die Verwendung von Infrastructure-as-Code (IaC) in Betracht ziehen, um die erforderliche Anwendungsinfrastruktur als Teil Ihrer CD-Pipeline zu erstellen oder zu aktualisieren.

Betrachten Sie beispielsweise diese Abbildungen, die zwei Ansätze zeigen, die GitHub Actions verwenden, um die Infrastruktur zu aktualisieren und in Azure Kubernetes Service bereitzustellen: eine mit pushbasierten Bereitstellungen und eine Pull-basierte Bereitstellung (GitOps).

Weitere Informationen zu den einzelnen Ansätzen finden Sie unter CI/CD für AKS-Apps mit GitHub Actions und Gitflow.

Was Sie auswählen, wird häufig von Ihren vorhandenen IaC-Qualifikationen und den Details Ihrer Zielanwendungsplattform bestimmt. Der GitOps-Ansatz ist neuer und ist bei Organisationen, die Kubernetes als Basis für ihre Anwendungen verwenden, beliebt, während das pullbasierte Modell Ihnen derzeit die größte Flexibilität bietet, da die Anzahl der verfügbaren Optionen dafür verfügbar ist. Wir erwarten, dass die meisten Organisationen eine Mischung aus beidem verwenden werden. Unabhängig davon können Sie sich gut mit IaC-Praktiken vertraut machen, um Muster zu erlernen, die für weitere Automatisierungsszenarien gelten.

Zentralisieren von IaC in einem Katalog oder einer Registrierung, um die Sicherheit zu skalieren und zu verbessern

Um IaC anwendungsübergreifend zu verwalten und zu skalieren, sollten Sie Ihre IaC-Artefakte zentral zur Wiederverwendung veröffentlichen. Beispielsweise können Sie Terraform-Module in einer Registrierung, Bicep-Module, Radius-Rezepte oder Helm-Diagramme verwenden, die in einer cloudnativen OCI-Artefaktregistrierung wie Azure Container Registry (ACR), DockerHub oder im Katalog in Azure Deployment Environments (ADE) gespeichert sind. Für GitOps und Kubernetes können Sie mit der Cluster-API (und Implementierungen wie CAPZ) Kubernetes-Workloadcluster verwalten, während benutzerdefinierte Ressourcendefinitionen wie Azure-Dienstoperator zusätzliche Unterstützung für andere Arten von Azure-Ressourcen und andere Tools wie crossplane-Supportressourcen in mehreren Clouds bereitstellen können. Diese ermöglichen es Ihnen, zentralisierte oder allgemeine Helm-Diagramme in etwa ACR für ein breiteres Spektrum von Szenarien zu verwenden.

Die Zentralisierung von IaC verbessert die Sicherheit, da Sie besser steuern können, wer Updates vornehmen kann, da diese nicht mehr mit Anwendungscode gespeichert werden. Es besteht weniger das Risiko eines versehentlichen Bruchs, der durch eine versehentliche Änderung während eines Codeupdates verursacht wird, wenn Experten, Betriebs- oder Plattformtechniker erforderliche Änderungen vornehmen. Entwickler profitieren auch von diesen Bausteinen, da sie keine vollständigen IaC-Vorlagen selbst erstellen müssen und automatisch von den codierten bewährten Methoden profitieren.

Welches IaC-Format Sie auswählen, hängt von Ihrem vorhandenen Skillsatz, der erforderlichen Steuerungsebene und dem verwendeten App-Modell ab. Beispielsweise sind Azure Container Apps (ACA) und das kürzliche experimentelle Radius OSS-Inkubationsprojekt meinungsreicher als die direkte Verwendung von Kubernetes, aber auch die Entwicklererfahrung optimieren. Das Trainingsmodul Beschreiben von Clouddiensttypen kann Ihnen helfen, die Vor- und Nachteile verschiedener Modelle zu verstehen. Unabhängig davon hat der Verweis auf zentralisierte und verwaltete IaC-Instanzen statt vollständiger Definitionen in Ihrer Quellstruktur erhebliche Vorteile.

Beibehalten erforderlicher Bereitstellungsidentitäten oder Geheimnisse so, dass Entwickler nicht direkt auf diese Ebenen in den grundlegenden Bausteinen für die Governance zugreifen können. Betrachten Sie beispielsweise diese Abbildung der Rollentrennung, die Sie mithilfe von Azure-Bereitstellungsumgebungen (Azure Deployment Environments, ADE) erreichen können.

Hier entwickeln Plattformtechniker und andere Spezialisten IaC und andere Vorlagen und platzieren sie in einem Katalog. Vorgänge können dann verwaltete Identitäten und Abonnements nach "Umgebungstyp" hinzufügen und Entwicklern und anderen Benutzern zuweisen, die diese für die Bereitstellung verwenden dürfen.

Entwickler oder Ihre CI/CD-Pipeline können dann die Azure CLI oder Azure Developer CLI verwenden, um vorkonfigurierte und kontrollierte Infrastruktur bereitzustellen, ohne überhaupt Zugriff auf das zugrunde liegende Abonnement oder die dafür erforderlichen Identitäten zu haben. Unabhängig davon, ob Sie etwas wie ADE verwenden oder nicht, kann Ihr Continuous Delivery-System Ihrer Wahl Ihnen helfen, die Infrastruktur sicher und sicher zu aktualisieren, indem Es Geheimnisse trennt und IaC-Inhalte von Standorten beschaffen, auf die Entwickler nicht selbst zugreifen oder diese ändern können.

Aktivieren von Self-Service in Szenarien, die über die Continuous Delivery von Anwendungen hinausgehen

Obwohl CI- und CD-Konzepte an die Anwendungsentwicklung gebunden sind, sind viele der Dinge, die Ihre internen Kunden bereitstellen möchten, nicht direkt mit einer bestimmten Anwendung verknüpft. Dies kann eine freigegebene Infrastruktur sein, das Erstellen eines Repositorys, Bereitstellungstools und vieles mehr.

Um zu verstehen, wo dies hilfreich sein könnte, überlegen Sie, wo Sie derzeit manuelle oder Service Desk-basierte Prozesse haben. Stellen Sie sich jeweils die folgenden Fragen vor:

• Wie oft geschieht dieser Prozess?
• Ist der Prozess langsam, fehleranfällig oder erfordert erhebliche Arbeit?
• Sind diese Prozesse aufgrund eines erforderlichen Genehmigungsschritts oder einfach aufgrund fehlender Automatisierung manuell?
• Wenn eine genehmigende Person benötigt wird, sind sie mit Quellcodeverwaltungssystemen und Pull Request-Prozessen vertraut?
• Welche Überwachungsanforderungen gelten für die Prozesse? Unterscheiden sich diese von den Überwachungsanforderungen Ihres Quellcodeverwaltungssystems?
• Gibt es Prozesse, mit denen Sie beginnen können, die ein geringeres Risiko darstellen, bevor Sie zu komplexeren Prozessen übergehen?

Identifizieren Sie häufige, hohe Anstrengung oder fehleranfällige Prozesse als potenzielle Ziele, um zuerst zu automatisieren. Als Nächstes behandeln wir einige einfache Möglichkeiten, dies zu ermöglichen.

Verwenden des Alles-als-Codemusters

Eines der schönen Dinge an Git ist zusätzlich zu seiner Allgegenwärtigkeit, dass es eine sichere, überprüfbare Informationsquelle sein soll. Über den Commitverlauf und Zugriffssteuerungen hinaus bieten Konzepte wie Pull Requests und Branchschutz eine Möglichkeit, bestimmte Prüfer, einen Konversationsverlauf und automatisierte Überprüfungen einzurichten, die vor dem Zusammenführen in den Standard Branch bestehen müssen. In Kombination mit flexiblen Task-Engines wie denen in CI/CD-Systemen verfügen Sie über ein sicheres Automatisierungsframework.

Die Idee hinter allem als Code ist, dass Sie fast alles in eine Datei in einem sicheren Git-Repository umwandeln können. Verschiedene Tools oder Agents, die mit dem Repository verbunden sind, können den Inhalt dann lesen. Das Behandeln von alles als Code erleichtert die Wiederholbarkeit durch Vorlagen und vereinfacht den Self-Service für Entwickler. Sehen Wir uns einige Beispiele an, wie dies funktionieren kann.

Anwenden von IaC-Mustern auf jede Infrastruktur

Während IaC bei der Automatisierung der Anwendungsbereitstellung an Popularität gewonnen hat, erstreckt sich das Muster auf alle Infrastrukturen, Tools oder Dienste, die Sie bereitstellen und konfigurieren möchten – nicht nur auf diejenigen, die an eine bestimmte Anwendung gebunden sind. Beispielsweise können Sie K8s mit Clustern mit installierten Flux-Clustern teilen, etwas wie DataDog bereitstellen, das von mehreren Teams und Anwendungen verwendet wird, oder sogar Ihre bevorzugten Tools für die Zusammenarbeit einrichten.

Dies funktioniert, dass Sie über ein separates, gesichertes zentrales Repository verfügen, das eine Reihe von Dateien enthält, die darstellen, was bereitgestellt und konfiguriert werden soll (in diesem Fall alles, von Bicep, Terraform bis hin zu Helm-Diagrammen und anderen nativen Kubernetes-Formaten). Ein Betriebsteam oder eine andere Gruppe von Administratoren ist Besitzer des Repositorys, und Entwickler (oder Systeme) können Pull Requests übermitteln. Sobald diese PRs von diesen Administratoren in den Standard-Branch zusammengeführt wurden, können dieselben CI/CD-Tools, die während der Anwendungsentwicklung verwendet werden, für die Verarbeitung der Änderungen eingesetzt werden. Betrachten Sie diese Abbildung, die GitHub Actions und IaC und Bereitstellungsidentitäten verwendet, die in Azure-Bereitstellungsumgebungen untergebracht sind:

Wenn Sie bereits einen GitOps-Ansatz für die Anwendungsbereitstellung verwenden, können Sie auch diese Tools wiederverwenden. Durch die Kombination von Tools wie Flux und Azure Service Operator können Sie auch außerhalb von Kubernetes expandieren:

In beiden Fällen verfügen Sie über eine vollständig verwaltete, reproduzierbare und überprüfbare Informationsquelle – auch wenn das, was produziert wird, nicht für eine Anwendung ist. Wie bei der Anwendungsentwicklung können alle Geheimnisse oder verwalteten Identitäten, die Sie benötigen, in der Pipeline-/Workflow-Engine oder in den nativen Funktionen eines Bereitstellungsdiensts gespeichert werden.

Da die Personen, die die PRs erstellen, keinen direkten Zugriff auf diese Geheimnisse haben, bietet es Entwicklern eine Möglichkeit, Aktionen sicher zu initiieren, für die sie keine direkte Berechtigung haben. Dadurch können Sie das Prinzip der geringsten Rechte einhalten und gleichzeitig Entwicklern eine Self-Service-Option bieten.

Nachverfolgen der bereitgestellten Infrastruktur

Wenn Sie mit der Skalierung dieses Ansatzes beginnen, überlegen Sie, wie Sie die bereitgestellte Infrastruktur nachverfolgen möchten. Ihr Git-Repository ist eine Quelle der Wahrheit für die Konfiguration, teilt Ihnen aber nicht die spezifischen URIs und Zustandsinformationen zu dem, was Sie erstellt haben. Wenn Sie jedoch einen Alles-als-Code-Ansatz verfolgen, erhalten Sie eine Informationsquelle, die Sie nutzen können, um einen Bestand der bereitgestellten Infrastruktur zu synthetisieren. Ihr Bereitstellungsgeber kann auch eine gute Quelle für diese Informationen sein, die Sie nutzen können. Azure-Bereitstellungsumgebungen umfassen beispielsweise Funktionen zur Umgebungsnachverfolgung, in die Entwickler Einblick haben.

Weitere Informationen zur Nachverfolgung in verschiedenen Datenquellen finden Sie unter Entwerfen einer Self-Service-Basis für Entwickler.

Anwenden der Sicherheit als Code und Richtlinie als Codemuster

Obwohl die Bereitstellung der Infrastruktur nützlich ist, ist es genauso wichtig, sicherzustellen, dass diese Umgebungen sicher sind und sich im Allgemeinen an die Richtlinien Ihrer organization halten. Dies hat zum Aufkommen des Konzepts "Policy as Code" geführt. Hier können Konfigurationsdateien in einem Quellcodeverwaltungsrepository verwendet werden, um z. B. sicherheitsrelevante Überprüfungen durchzuführen oder Infrastrukturrichtlinien anzuwenden.

Viele verschiedene Produkte und Open Source Projekte unterstützen diesen Ansatz, darunter Azure Policy, Open Policy Agent, GitHub Advanced Security und GitHub CODEOWNERS. Achten Sie bei der Auswahl Ihrer Anwendungsinfrastruktur, Dienste oder Tools darauf, zu bewerten, wie gut diese Muster unterstützt werden. Weitere Informationen zur Optimierung Ihrer Anwendung und Governance finden Sie unter Verfeinern Ihrer Anwendungsplattform.

Verwenden sie alles als Code für Ihre eigenen Szenarien

Alles als Code erweitert diese Muster auf eine Vielzahl von Automatisierungs- und Konfigurationsaufgaben über IaC hinaus. Es kann nicht nur das Erstellen oder Konfigurieren einer beliebigen Art von Infrastruktur unterstützen, sondern auch das Aktualisieren von Daten oder das Auslösen von Workflows in jedem nachgelagerten System.

Der PR wird zu einer guten grundlegenden Self-Service-Benutzeroberfläche für verschiedene Prozesse – insbesondere, wenn Sie beginnen. Die Prozesse erhalten natürlich die Vorteile von Sicherheit, Überprüfbarkeit und Rollback, die Git selbst bietet, und die beteiligten Systeme können sich auch im Laufe der Zeit ändern, ohne die Benutzererfahrung zu beeinträchtigen.

Teams als Code

Ein Beispiel für das Anwenden von alles als Code auf Ihre eigenen Szenarien sind die Teams als Codemuster. Organisationen wenden dieses Muster an, um die Teammitgliedschaft und in einigen Fällen die Entwicklertools-/Dienstberechtigungen für eine Vielzahl von Systemen zu standardisieren. Dieses Muster eliminiert das manuelle Onboarding und Offboarding von Service Desk-Prozessen, die von der Notwendigkeit für Systementwickler und -betreiber gesteuert werden, auf ihre eigenen Gruppierungs-, Benutzer- und Zugriffskonzepte zuzugreifen. Manuelle Service Desk-Prozesse sind ein potenzielles Sicherheitsrisiko, da es möglich ist, den Zugriff zu überlasten. Wenn Sie die Teams als Codemuster verwenden, kann die Kombination aus Git und Pull Requests Self-Service aus einer überprüfbaren Datenquelle aktivieren.

Ein Beispiel für eine ausgereifte, umfangreiche Variation dieses Musters finden Sie im GitHub-Blogbeitrag zur Verwaltung von Berechtigungen. GitHub hat auch ihre anspruchsvolle Berechtigungsimplementierung open-Source entwickelt, die Sie ausprobieren oder übernehmen können. Obwohl der Blogbeitrag alle Mitarbeiterberechtigungen beschreibt, können Sie das Team-Als-Code-Konzept auf eng gefasste Entwicklungsteamszenarien anwenden. Diese Entwicklungsteams sind möglicherweise überhaupt nicht in einem Mitarbeiter-Organigramm vertreten und umfassen proprietäre Tools oder Dienste, die das Onboarding oder das Offboarding von Teammitgliedern erschweren können.

Hier finden Sie eine Zusammenfassung einer vereinfachten Variante dieser Idee, die ein CI/CD-System und Identitätsanbietergruppen verwendet, um Updates zu koordinieren:

Für dieses Beispiel wird folgendes angenommen:

1. Jedes beteiligte System wurde so eingerichtet, dass Ihr Identitätsanbieter (z. B. Microsoft Entra ID) für einmaliges Anmelden (Single Sign-On, SSO) verwendet wird.
2. Sie verwenden Identitätsanbietergruppen (z. B. Entra-Gruppen) systemübergreifend, um die Mitgliedschaft nach Rolle zu verwalten, um die Komplexität zu verringern und die zentrale Überwachung aufrechtzuerhalten.

Auf hoher Ebene funktioniert dieses Muster wie folgt:

1. Ein zentrales, gesperrtes Git-Repository enthält eine Reihe von Dateien (in der Regel YAML), die jedes abstrakte Team, die zugehörige Benutzermitgliedschaft und die Benutzerrollen darstellen. Besitzer/Genehmigende für Teamänderungen können auch an derselben Stelle gespeichert werden (z. B. über CODEOWNERS). Der Verweis auf einen Benutzer in diesen Dateien ist der Identitätsanbieter, aber dieses Repository fungiert als Quelle der Wahrheit für diese Teams (aber nicht für Benutzer).
2. Wie in anderen Codefällen erfolgen alle Aktualisierungen dieser Dateien über Pull Requests. Dies bindet Unterhaltungen und verwandte Teilnehmer bei der Anforderung zum Git-Commit zur Überprüfbarkeit.
3. Leads und einzelne Benutzer können PRs erstellen, um Personen hinzuzufügen/zu entfernen, und Entwicklungsleiter und andere Rollen können neue Teams mithilfe von PRs erstellen, die eine neue Teamdatei aus einer Vorlage enthalten.
4. Wenn ein PR in Standard zusammengeführt wird, aktualisiert ein CI/CD-System, das an das Repository gebunden ist, das Identitätsanbietersystem und alle nachgelagerten Systeme nach Bedarf.

Insbesondere das CI/CD-System:

5. Verwendet die entsprechende Identitätsanbieter-System-API, um eine Identitätsanbietergruppe pro Rolle mit genau den Personen in der Datei zu erstellen oder zu aktualisieren (nicht mehr, nicht weniger).
6. Verwendet APIs für jedes nachgelagerte System, um dieses Systemgruppierungskonzept mit einem identifizierenden Anbietergruppen für jede Rolle zu verknüpfen (Beispiel: GitHub und Azure DevOps). Dies kann zu einer 1:n-Beziehung zwischen Ihrem Team und dem nachgeschalteten System führen, um eine Rolle darzustellen.
7. Optional werden APIs für jedes nachgeschaltete System verwendet, um Berechtigungslogik zu implementieren, die an den Gruppierungsmechanismus des Systems gebunden ist.
8. Verwendet eine API, um einen gesperrten Datenspeicher mit den Ergebnissen zu aktualisieren (einschließlich der Zuordnung der nachgelagerten Systemteam-IDs), die dann für jedes Ihrer intern erstellten Systeme verwendet werden können. Sie können hier bei Bedarf auch Zuordnungen für verschiedene Systemdarstellungen von Benutzer-IDs für denselben Identitätsanbieterbenutzer bzw. dasselbe Konto speichern.

Beachten Sie, dass Sie die Verwaltung der Gruppenmitgliedschaft in diesem Muster möglicherweise weglassen können, wenn Ihr organization bereits eine Art Entra-Berechtigungsverwaltung verwendet.

Ihre Anforderungen und Richtlinien können die Besonderheiten ändern, aber das allgemeine Muster kann an eine beliebige Anzahl von Variationen angepasst werden. Alle Geheimnisse, die für die Integration in nachgelagerte Systeme erforderlich sind, werden entweder im CI/CD-System (z. B. in GitHub Actions, Azure Pipelines) oder in azure Key Vault verwaltet.

Verwenden manueller oder extern ausgelöster, parametrisierter Workflows

Einige der Self-Service-bezogenen Probleme, die Sie identifizieren, sind möglicherweise nicht förderlich für die Verwendung von Dateien in Git. Oder Sie verfügen über eine Benutzeroberfläche, die Sie verwenden möchten, um die Self-Service-Benutzeroberfläche zu verbessern.

Glücklicherweise verfügen die meisten CI-Systeme, einschließlich GitHub Actions und Azure Pipelines, über die Möglichkeit, einen Workflow mit Eingaben einzurichten, die Sie dann manuell über ihre UIs oder CLIs auslösen können. Da Entwickler und verwandte Betriebsrollen wahrscheinlich bereits mit diesen Benutzeroberflächen vertraut sind, können manuelle Trigger das Alles als Codemuster erweitern, um die Automatisierung für Aktivitäten (oder Aufträge) zu ermöglichen, die entweder keine natürliche Dateidarstellung haben oder vollständig automatisiert sein sollten, ohne dass ein PR-Prozess erforderlich ist.

Ihr CI-System kann es Ihnen sogar ermöglichen, diese Workflows/Pipelines über Ihre eigenen Benutzererfahrungen über eine API auszulösen. Für GitHub Actions ist der Schlüssel dazu die Actions-REST-API zum Auslösen eines Workflowversandereignisses, um eine Workflowausführung auszulösen. Azure DevOps-Trigger sind ähnlich, und Sie können auch die Azure DevOps-Pipeline-API für Ausführungen verwenden. Sie werden wahrscheinlich die gleichen Funktionen in anderen Produkten sehen. Unabhängig davon, ob sie manuell oder über eine API ausgelöst werden, kann jeder Workflow eine Reihe von Eingaben unterstützen, indem er der WORKFLOW-YAML-Datei eine workflow_dispatch Konfiguration hinzufügt. Beispielsweise interagieren Portal-Toolkits wie Backstage.io mit GitHub Actions.

Der Workflow/Das Auftragssystem Ihres CI/CD-Systems verfolgt zweifellos Aktivitäten nach, meldet status zurück und verfügt über detaillierte Protokolle, die sowohl Entwickler als auch Betriebsteams verwenden können, um zu sehen, was schief gelaufen ist. Auf diese Weise bietet es einige der gleichen Sicherheits-, Überprüfbarkeits- und Sichtbarkeitsvorteile wie das Alles-als-Code-Muster. Zu beachten ist jedoch, dass alle Aktionen, die von diesen Workflows/Pipelines ausgeführt werden, für nachgeschaltete Systeme wie eine Systemidentität aussehen (z. B. Dienstprinzipal oder verwaltete Identität in Microsoft Entra ID).

Sie haben einblick, wer Anforderungen in Ihrem CI/CD-System initiiert, aber Sie sollten beurteilen, ob dies genügend Informationen sind, und sicherstellen, dass Ihre CI/CD-Aufbewahrungseinstellungen Ihren Überwachungsanforderungen für Fälle entsprechen, in denen diese Informationen kritisch sind.

In anderen Fällen verfügen die Tools, mit denen Sie integrieren, möglicherweise über eigene Nachverfolgungsmechanismen, auf die Sie sich verlassen können. Beispielsweise verfügen diese CI/CD-Tools fast immer über mehrere Benachrichtigungsmechanismen, z. B. über einen Microsoft Teams- oder Slack-Kanal, mit denen Sie eine Anforderung zum Abrufen status Updates übermitteln können, und der Kanal stellt eine informelle Aufzeichnung der Geschehnisse bereit. Dieselben Workflows-Engines sind häufig bereits für die Integration in Betriebstools konzipiert, um die Nützlichkeit dieser Muster weiter zu erweitern.

Zusammenfassend lässt sich sagen, dass Sie mithilfe von Dateien, die in einem Quellcodeverwaltungsrepository gespeichert sind, dank der Flexibilität der CI/CD-Tools und ihrer vordefinierten Benutzeroberfläche eine gewisse Automatisierung implementieren können.

Informationen dazu, wie interne Entwicklerplattformen diesen Ansatz als Ausgangspunkt nutzen können, ohne im Laufe der Zeit Kompromisse bei anspruchsvolleren Funktionen einzugehen, finden Sie unter Entwerfen einer Self-Service-Grundlage für Entwickler.

Automatisieren der Einrichtung von Entwicklercodierungsumgebungen

Ein weiteres häufiges Problem, bei dem Sie möglicherweise feststellen, dass Ihre Technischen Systeme helfen können, ist das Bootstrapping und die Normalisierung der Entwicklercodierungsumgebung. Hier sind einige der häufigsten Probleme, von denen Sie in diesem Bereich möglicherweise hören:

• In einigen Fällen kann es Wochen dauern, bis ein Entwickler seinen ersten Pull Request erhält. Dies ist ein problematischer Bereich, wenn Sie Entwickler relativ häufig zwischen Featureteams und Projekten übertragen (z. B. in matrixierten Organisationen), Auftragnehmer hochfahren müssen oder sich in einem Team befinden, das sich in einer Einstellungsphase befindet.
• Inkonsistenz zwischen Entwicklern und Ihren CI-Systemen kann auch für erfahrene Teammitglieder zu häufigen Problemen führen, die auf meinem Computer funktionieren.
• Experimentieren und Aktualisieren von Frameworks, Laufzeiten und anderer Software können auch vorhandene Entwicklerumgebungen unterbrechen und dazu führen, dass Zeit verloren geht, um genau herauszufinden, was schief gelaufen ist.
• Für Entwickler können Codeüberprüfungen die Entwicklung verlangsamen, da sie möglicherweise eine Konfigurationsänderung erfordern, um sie zu testen und rückgängig zu machen, sobald die Überprüfung abgeschlossen ist.
• Teammitglieder und Operatoren müssen auch zeitaufwenden, um verwandte Rollen über die Entwicklung hinaus (Operatoren, QA, Unternehmen, Sponsoren) hochzufahren, um zu testen, fortschritte zu sehen, Geschäftsrollen zu trainieren und die Arbeit des Teams zu evangelisieren.

Teil Ihrer gepflasterten Pfade

Um diese Probleme zu beheben, denken Sie an die Einrichtung bestimmter Tools und Hilfsprogramme als Teil Ihrer klar definierten, gepflasterten Pfade. Das Einrichten von Skriptentwicklercomputern kann hilfreich sein, und Sie können dieselben Skripts in Ihrer CI-Umgebung wiederverwenden. Erwägen Sie jedoch die Unterstützung containerisierter oder virtualisierter Entwicklungsumgebungen aufgrund der Vorteile, die sie bieten können. Diese Codierungsumgebungen können im Voraus gemäß den Spezifikationen Ihres organization oder Projekts eingerichtet werden.

Ersatz von Arbeitsstationen und Ziel für Windows

Wenn Sie entweder auf Windows abzielen oder eine vollständige Arbeitsstationsvirtualisierung durchführen möchten (neben projektspezifischen Einstellungen auch Clienttools und Hostbetriebssystemeinstellungen), bieten VMs in der Regel die beste Funktionalität. Diese Umgebungen können für alles nützlich sein, von der Windows-Cliententwicklung über den Windows-Dienst bis hin zum Verwalten und Verwalten von vollständigen .NET-Framework-Webanwendungen.

Vorgehensweise	Beispiele
Verwenden von in der Cloud gehosteten VMs	Microsoft Dev Box ist eine vollständige Virtualisierungsoption für Windows-Arbeitsstationen mit integrierter Integration in Die Desktopverwaltungssoftware.
Verwenden lokaler VMs	Hashicorp Vagrant ist eine gute Option, und Sie können HashiCorp Packer verwenden, um VM-Images sowohl für ihn als auch für Dev Box zu erstellen.

Arbeitsbereichsvirtualisierung und Linux-Ziel

Wenn Sie Linux als Ziel haben, sollten Sie eine Option zur Arbeitsbereichsvirtualisierung in Erwägung ziehen. Diese Optionen konzentrieren sich weniger auf das Ersetzen Ihres Entwicklerdesktops als auf projekt- oder anwendungsspezifische Arbeitsbereiche.

Vorgehensweise	Beispiele
Verwenden von in der Cloud gehosteten Containern	GitHub Codespaces ist eine cloudbasierte Umgebung für Dev Containers, die die Integration mit VS Code, JetBrains' IntelliJ und terminalbasierten Tools unterstützt. Wenn dieser oder ein ähnlicher Dienst Ihre Anforderungen nicht erfüllt, können Sie die SSH- oder Remotetunnelunterstützung von VS Code mit Dev Containers auf virtuellen Remotecomputern unter Linux verwenden. Die tunnelbasierte Option, die nicht nur mit dem Client funktioniert, sondern auch die webbasierte vscode.dev.
Verwenden lokaler Container	Wenn Sie stattdessen oder zusätzlich zu einer in der Cloud gehosteten Option eine lokale Dev-Container-Option bevorzugen möchten, verfügen Dev Container über eine solide Unterstützung in VS Code, Unterstützung in IntelliJ und andere Tools und Dienste.
Verwenden von in der Cloud gehosteten VMs	Wenn Sie Container als zu einschränkend empfinden, können Sie mithilfe der SSH-Unterstützung in Tools wie VS Code oder JetBrains-Tools wie IntelliJ eine direkte Verbindung mit linux-VMs herstellen, die Sie selbst verwalten. VS Code verfügt auch über eine tunnelbasierte Option .
Verwenden des Windows-Subsystem für Linux	Wenn Ihre Entwickler ausschließlich unter Windows arbeiten, ist Windows-Subsystem für Linux (WSL) eine hervorragende Möglichkeit für Entwickler, linux lokal zu verwenden. Sie können eine WSL-Verteilung für Ihr Team exportieren und sie für alle eingerichteten Elemente freigeben. Für eine Cloudoption können Cloudarbeitsstationsdienste wie Microsoft Dev Box auch WSL für die Linux-Entwicklung nutzen.

Erstellen von richtigen Startanwendungsvorlagen, die die richtige Konfiguration enthalten

Das Tolle am Alles-als-Code-Muster ist, dass es Entwickler auf den gepflasterten Pfaden halten kann, die Sie von Anfang an eingerichtet haben. Wenn dies eine Herausforderung für Ihre organization ist, können Anwendungsvorlagen schnell zu einer wichtigen Möglichkeit werden, Bausteine wiederzuverwenden, um die Konsistenz zu fördern, die Standardisierung zu fördern und die bewährten Methoden Ihrer organization zu codieren.

Zunächst können Sie ein so einfaches GitHub-Vorlagenrepository verwenden, aber wenn Ihr organization einem Monorepo-Muster folgt, ist dies möglicherweise weniger effektiv. Sie können auch Vorlagen erstellen, mit denen Sie etwas einrichten können, das nicht direkt mit einer Quellstruktur der Anwendung zusammenhängt. Stattdessen können Sie eine Templating-Engine wie cookiecutter, Yeoman oder so etwas wie die Azure Developer CLI (azd) verwenden, die neben Vorlagenerstellung und vereinfachtem CI/CD-Setup auch eine praktische Reihe von Entwicklerbefehlen bereitstellt. Da der Azure Developer CLI verwendet werden kann, um die Umgebungseinrichtung in allen Szenarien zu steuern, ist es in Azure-Bereitstellungsumgebungen integriert, um verbesserte Sicherheit, integrierte IaC, Umgebungsnachverfolgung, Trennung von Bedenken und vereinfachtes CD-Setup zu bieten.

Sobald Sie über eine Reihe von Vorlagen verfügen, können Entwicklerleiter diese Befehlszeilentools oder andere integrierte Benutzeroberflächen verwenden, um ihre Inhalte für ihre Anwendungen zu gerüsten. Da Entwickler jedoch möglicherweise nicht berechtigt sind, Repositorys oder andere Inhalte aus Ihren Vorlagen zu erstellen, ist dies eine weitere Möglichkeit, manuell ausgelöste, parametrisierte Workflows/Pipelines zu verwenden. Sie können Eingaben einrichten, damit Ihr CI/CD-System alles von einem Repository bis zur Infrastruktur in ihrem Namen erstellt.

Richtig bleiben und richtig werden

Um die Skalierung zu erleichtern, sollten diese Anwendungsvorlagen jedoch nach Möglichkeit auf zentralisierte Bausteine verweisen (z. B. IaC-Vorlagen oder sogar CI/CD-Workflows/Pipelines). Möglicherweise stellen Sie fest, dass die Behandlung dieser zentralen Bausteine als ihre eigene Form der richtigen Startvorlagen eine effektive Strategie ist, um einige der von Ihnen identifizierten Probleme zu lösen.

Jede dieser einzelnen Vorlagen kann nicht nur auf neue Anwendungen angewendet werden, sondern auch auf vorhandene, die Sie im Rahmen einer Get Right-Kampagne aktualisieren möchten, um aktualisierte oder verbesserte Richtlinien auszurollen. Noch besser: Diese Zentralisierung hilft Ihnen, sowohl neue als auch vorhandene Anwendungen richtig zu halten, sodass Sie Ihre bewährten Methoden im Laufe der Zeit weiterentwickeln oder erweitern können.

Vorlageninhalt

Es wird empfohlen, beim Erstellen von Vorlagen die folgenden Bereiche zu berücksichtigen.

Bereich	Details
Genügend Beispielquellcode zum Steuern von App-Mustern, SDKs und Toolverwendung	Fügen Sie Code und Konfiguration ein, um Entwickler zu empfohlenen Sprachen, App-Modellen und Diensten, APIs, SDKs und Architekturmustern zu steuern. Stellen Sie sicher, dass Sie Code für verteilte Ablaufverfolgung, Protokollierung und Beobachtbarkeit mit Den tools Ihrer Wahl einschließen.
Erstellen und Bereitstellen von Skripts	Bieten Sie Entwicklern eine gängige Möglichkeit, einen Build und eine lokale/Sandboxbereitstellung auszulösen. Fügen Sie die Debugkonfiguration in IDE/Editor für die Tools Ihrer Wahl ein, um sie zu verwenden. Dies ist ein wichtiger Weg, um Wartungsschmerzen zu vermeiden und zu verhindern, dass CI/CD nicht synchron sind. Wenn Ihre Vorlagen-Engine wie die Azure Developer CLI ist, gibt es möglicherweise bereits Befehle, die Sie einfach verwenden können.
Konfiguration für CI/CD	Stellen Sie Workflows/Pipelines zum Erstellen und Bereitstellen von Anwendungen basierend auf Ihren Empfehlungen bereit. Nutzen Sie zentralisierte, wiederverwendbare oder vorlagenbasierte Workflows/Pipelines, um sie auf dem neuesten Stand zu halten. In der Tat können diese wiederverwendbaren Workflows / Pipelines ihre eigenen vorlagen. Stellen Sie sicher, dass Sie eine Option in Betracht ziehen, um diese Workflows manuell auszulösen.
Infrastruktur als Coderessourcen	Stellen Sie empfohlene IaC-Konfigurationen bereit, einschließlich Verweise auf zentral verwaltete Module oder Katalogelemente , um sicherzustellen, dass jede Infrastruktureinrichtung von Anfang an bewährte Methoden befolgt. Diese Verweise können teams auch dabei helfen, mit der Zeit richtig zu bleiben. In Kombination mit Workflows/Pipelines können Sie auch IaC oder EaC einschließen, um so gut wie alles bereitzustellen.
Sicherheit und Richtlinien als Coderessourcen	Die DevSecOps-Bewegung hat auch die Sicherheitskonfiguration in Code verschoben, was sich hervorragend für Vorlagen eignet. Einige Richtlinien als Codeartefakte können auch auf Anwendungsebene angewendet werden. Schließen Sie alles ein, von Dateien wie CODEOWNERS bis hin zu Scankonfigurationen wie dependabot.yaml in GitHub Advanced Security. Stellen Sie geplante Workflows/Pipelineausführungen für Scans bereit, die z. B . Defender für Cloud zusammen mit Umgebungstestausführungen verwenden. Dies ist besonders wichtig für die Lieferkettensicherheit, und achten Sie darauf, containerimages zusätzlich zu Anwendungspaketen und Code zu berücksichtigen. Diese Schritte helfen Entwicklungsteams dabei, richtig zu bleiben.
Beobachtbarkeit, Überwachung und Protokollierung	Ein Teil der Aktivierung von Self-Service besteht darin, nach der Bereitstellung einen einfachen Einblick in Anwendungen zu bieten. Achten Sie über die Laufzeitinfrastruktur hinaus darauf, das Setup für Die Beobachtung und Überwachung einzubeziehen. In den meisten Fällen muss ein IaC-Aspekt eingerichtet werden (z. B. Agentbereitstellung, Instrumentierung), während es sich in anderen Fällen um einen anderen Typ von Config-as-Codeartefakt handeln kann (z. B. Überwachen von Dashboards für Azure-Anwendung Insights). Schließlich sollten Sie Codebeispielcode für die verteilte Ablaufverfolgung, Protokollierung und Beobachtbarkeit mithilfe der von Ihnen gewählten Tools einschließen.
Einrichtung der Codierungsumgebung	Schließen Sie Konfigurationsdateien zum Codieren von Lintern, Formatierern, Editoren und IDEs ein. Schließen Sie Setupskripts zusammen mit Arbeitsbereichs- oder Arbeitsstationsvirtualisierungsdateien wie devcontainer.json, devbox.yaml, entwicklerorientierte Dockerfiles, Docker Compose-Dateien oder Vagrantfiles ein.
Testkonfiguration	Stellen Sie Konfigurationsdateien für Komponenten und ausführlichere Tests mit Ihren bevorzugten Diensten wie Microsoft Playwright Testing für ui oder Azure Load Testing bereit.
Einrichten des Zusammenarbeitstools	Wenn Ihr Problemverwaltungs- und Quellcodeverwaltungssystem Aufgaben-/Problem-/PR-Vorlagen als Code unterstützt, schließen Sie auch diese ein. In Fällen, in denen mehr Setup erforderlich ist, können Sie optional einen Workflow/eine Pipeline bereitstellen, die Ihre Systeme mithilfe einer verfügbaren CLI oder API aktualisiert. Auf diese Weise können Sie auch andere Tools für die Zusammenarbeit wie Microsoft Teams oder Slack einrichten.

Verfeinern Ihrer Anwendungsplattform