Anwenden von Softwareentwicklungssystemen

Artikel
07/25/2024

Die Verbesserung von Self-Service für Entwickler sollte eines der ersten Probleme sein, die Sie in Ihrer Plattform-Engineering-Reise angehen.

Eine der einfachsten Möglichkeiten, mit der Aktivierung automatisierter Self-Service-Erfahrungen zu beginnen, besteht darin, Ihre vorhandenen Engineering-Systeme wiederzuverwenden. Diese Systeme sind Ihnen und Ihren internen Kunden nicht nur vertraut, sondern können auch dann eine breite Palette von Automatisierungsszenarien ermöglichen, wenn die anfängliche Benutzererfahrung nicht ziemlich ist.

Dieser Artikel enthält Tipps zum Anwenden Ihrer Engineering-Systeme, um eine breitere Palette von Self-Service-Szenarien anzugehen, und Details zum Kapseln bewährter Methoden in Vorlagen, die Ihnen helfen, richtig zu beginnen und richtig zu bleiben.

Bewerten Ihrer Grundlegenden DevOps- und DevSecOps-Methoden

Engineering-Systeme sind ein wichtiger Aspekt Ihrer internen Entwicklerplattform. Interne Entwicklerplattformen bauen aus den Hauptmandanten von DevOps und DevSecOps auf, um die kognitive Belastung für alle Beteiligten zu reduzieren.

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

Abbildung des DevOps-Lebenszyklus mit Plan, Bereitstellung, Entwicklung, Betrieb.

Die folgenden Abschnitte konzentrieren sich auf Verbesserungen, die direkter auf die Plattformentwicklung zurückzuführen sind: gepflasterte Pfade, automatisierte Infrastrukturbereitstellung (zusätzlich zur Anwendungsbereitstellung), Codierumgebungseinrichtung sowie Self-Service-Bereitstellung und Konfiguration von Tools, Teamressourcen und Diensten, die nicht direkt Teil der Anwendungsentwicklungsschleife sind.

Einrichten der gewünschten gepflasterten Wege

Wenn Sie bereits über mehrere Tools verfügen, die Ihre Engineering-Systeme bilden, ist eine frühe Entscheidung, ob Sie sie als Teil Ihrer ersten Plattform engineering-Bemühungen konsolidieren möchten oder ob Sie eine Konstellation verschiedener Tools von Anfang an unterstützen. Das Definieren einer Reihe von gepflasterten Wegen innerhalb dieser Konstellation von Werkzeugen ist am effektivsten und bietet ein erhöhtes Maß an Flexibilität.

Wenn Sie mit dem Umstieg auf eine Produkt-Denkweise beginnen, denken Sie an die Engineering-Systeme innerhalb dieser gepflasterten Wege, da sie aus Tools bestehen, die zentral als Dienst für Entwicklungsteams verwaltet werden. Einzelne Teams oder Abteilungen innerhalb Ihrer Organisation können dann abweichen, aber erwartet werden, dass sie ihre Tools separat verwalten, verwalten und bezahlen, während sie weiterhin den Complianceanforderungen entsprechen. Dies bietet eine Möglichkeit, neue Werkzeuge ohne Unterbrechung in das Ökosystem einzuspeisen, da Sie alles auswerten können, was für die mögliche Einbeziehung in einen gepflasterten Weg im Laufe der Zeit abweicht. Als ein Plattform-Engineering-Lead:

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

Angesichts der Tatsache, dass ein wichtiges Ziel für das Plattform-Engineering darin besteht, zu einer Produkt-Denkweise zu wechseln, in der Sie Ihren internen Kunden Wert bieten, funktioniert dieser Konstellationsansatz in der Regel besser als ein Top-Down-Mandat. Wenn Sie Ihre gepflasterten Pfade einrichten und verfeinern, ermöglicht es Teams, Eingaben bereitzustellen und wirklich einzigartige Anforderungen für eine bestimmte Anwendung zu erfüllen, ohne andere in der Organisation zu beeinträchtigen. Dies führt zu einer Reihe vollständig gepflasterter, goldener Wege, während andere nur teilweise gepflastert sind. In Fällen, in denen keine eindeutigen Anforderungen bestehen, werden die zusätzlichen Arbeitsentwicklungsteams natürlich dazu führen, dass sie im Laufe der Zeit zu einem unterstützten Pfad wechseln möchten.

Wenn Sie eine Konsolidierungsstrategie bevorzugen, ist das Migrieren vorhandener Anwendungen möglicherweise mehr Arbeit als erwartet, daher sollten Sie sich wahrscheinlich auf den richtigen Startaspekt dieses Raums konzentrieren und sich auf neue Projekte konzentrieren. Dies gibt Ihnen Ihren ersten gepflasterten Weg, während alles, was vorhanden ist, inhärent ist. Entwicklungsteams auf dem nicht gesicherten Weg werden dann in Betracht ziehen, zu verschieben, sobald Ihr neuer gepflasterter Pfad seinen Wert für die Organisation anzeigt. An diesem Punkt können Sie eine get right Kampagne ausführen, um jeden über die bidirektionale Kommunikation auf Ihren gewünschten Zustand zu bringen, da Entwicklungsteams dies als Vorteil und nicht als Steuer betrachten. Während der Kampagne können plattformtechnische Teams sich auf die Migration von Teams konzentrieren, während die Entwicklerteams Feedback geben, wie sie die gepflasterten Wege verbessern können.

Vermeiden Sie unabhängig davon die Verwendung Ihrer gepflasterten Wege. Die effektivste Möglichkeit, gepflasterte Wege zu einführen, besteht darin, hervorzuheben, was Teams aus ihnen herausholen, anstatt durch erzwungene Einführung. Da sich Ihre interne Entwicklerplattform darauf konzentriert, diese genau gleichen Teams glücklich zu machen, budgetieren und Zeit-zu-Wert-Druck auf einzelne Führungskräfte kümmert sich um den Rest. Holen Sie sich die richtigen Kampagnen und bieten Sie dann eine Möglichkeit für bidirektionale Unterhaltungen auf dem besten Weg für diejenigen auf einem unpavierten Weg, um zu wechseln.

Verwenden sie Entwicklerautomatisierungstools, um Self-Service für Ihre gepflasterten Pfade zu verbessern

Ein Teil der Erstellung Ihres ersten gepflasterten Pfads sollte sein, um Ihre wichtigsten Entwicklerautomatisierungsprodukte einzurichten. Diese sind wichtig, wenn Sie beginnen, die Self-Service-Funktionen von Entwicklern zu aktivieren.

Aktivieren der automatischen Bereitstellung der Anwendungsinfrastruktur während der kontinuierlichen Bereitstellung

Wenn sie noch nicht implementiert wurden, werden die Probleme, die Sie während der Planung identifiziert haben, wahrscheinlich auf Probleme hinweisen, die eine kontinuierliche Integration (Continuous Integration, CI) und eine kontinuierliche Lieferung (Continuous Delivery, CD) zur Lösung beitragen können. Produkte wie GitHub Actions, Azure DevOps, Jenkins und Pull-basierte GitOps-Lösungen wie Flux oder Argo CD existieren in diesem Bereich. Sie können mit diesen Themen im Microsoft DevOps-Ressourcencenter beginnen.

Auch wenn Sie bereits eine Möglichkeit implementiert haben, Ihre Anwendung kontinuierlich in einer vorhandenen Infrastruktur bereitzustellen, sollten Sie die Verwendung der Infrastruktur als 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-Aktionen verwenden, um die Infrastruktur zu aktualisieren und in Azure Kubernetes Service bereitzustellen: eine mit Push-basierten Bereitstellungen und eine Pull-basierte (GitOps)-Bereitstellung.

Welche Sie auswählen, wird von Ihrem vorhandenen IaC-Qualifikationssatz und den Details Ihrer Zielanwendungsplattform gesteuert. Der GitOps-Ansatz ist neuer und ist bei Organisationen beliebt, die Kubernetes als Basis für ihre Anwendungen verwenden, während das Pull-basierte Modell Ihnen derzeit die größte Flexibilität bei der Anzahl der verfügbaren Optionen bietet. Wir erwarten, dass die meisten Organisationen eine Mischung aus den beiden verwenden. Unabhängig davon, dass Sie in IaC-Praktiken gut vertraut sind, können Sie Muster erlernen, die sich auf weitere Automatisierungsszenarien beziehen.

Zentralisieren von IaC in einem Katalog oder einer Registrierung zum Skalieren und Verbessern der Sicherheit

Um IaC für alle Anwendungen zu verwalten und zu skalieren, sollten Sie Ihre IaC-Artefakte zentral zur Wiederverwendung veröffentlichen. Sie können beispielsweise Terraform-Module in einer Registrierung, Bicep-Modulen, Radiusrezepten oder Helmdiagrammen verwenden, die in einer cloudeigenen OCI Artifact-Registrierung wie Azure Container Registry (ACR), DockerHub oder dem Katalog in Azure Deployment Environments (ADE) gespeichert sind. Bei GitOps und Kubernetes können Sie mit der Cluster-API (und Implementierungen wie CAPZ) Kubernetes-Workloadcluster verwalten, während benutzerdefinierte Ressourcendefinitionen wie Azure Service Operator zusätzliche Unterstützung für andere Arten von Azure-Ressourcen, andere Tools wie Crossplane-Supportressourcen in mehreren Clouds bereitstellen können. Auf diese Weise können Sie zentrale oder allgemeine Helmdiagramme in etwa ACR für eine breitere Palette von Szenarien verwenden.

Durch die Zentralisierung von IaC wird die Sicherheit verbessert, indem Sie besser steuern, wer Updates vornehmen kann, da sie nicht mehr mit Anwendungscode gespeichert sind. Es besteht weniger das Risiko einer versehentlichen Unterbrechung, die 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 codierten bewährten Methoden profitieren.

Welches IaC-Format Sie auswählen, hängt von Ihrem vorhandenen Qualifikationssatz, der benötigten Steuerungsebene und dem verwendeten App-Modell ab. So sind z. B . Azure Container Apps (ACA) und das aktuelle experimentelle Radius OSS Incubation-Projekt stärker als kubernetes direkt zu verwenden, sondern auch die Entwicklererfahrung zu optimieren. Das Schulungsmodul "Beschreiben von Clouddiensttypen " kann Ihnen helfen, die Vor- und Nachteile verschiedener Modelle zu verstehen. Unabhängig davon hat das Verweisen auf zentralisierte und verwaltete IaC- und keine vollständigen Definitionen in Ihrer Quellstruktur erhebliche Vorteile.

Beibehalten erforderlicher Bereitstellungsidentitäten oder geheimer Schlüssel auf eine Weise, die Entwickler nicht direkt auf diese Ebenen in den grundlegenden Bausteinen für Governance zugreifen können. Betrachten Sie beispielsweise diese Abbildung der Rollentrennung, die Sie mit Azure Deployment Environments (ADE) erreichen können.

Hier entwickeln Plattformingenieure 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 sie 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 auch zugriff auf das zugrunde liegende Abonnement oder die zugrunde liegenden Identitäten zu haben, die dazu erforderlich sind. Unabhängig davon, ob Sie etwas wie ADE verwenden oder nicht, kann Ihr kontinuierliches Bereitstellungssystem Ihnen helfen, die Infrastruktur sicher und sicher zu aktualisieren, indem Sie geheime Schlüssel und IaC-Inhalte von Speicherorten trennen, auf die Entwickler nicht selbst zugreifen oder ändern können.

Aktivieren von Self-Service in Szenarien, die über die kontinuierliche Bereitstellung der Anwendung hinausgehen

Während 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 gemeinsam genutzte Infrastruktur sein, ein Repository erstellen, Bereitstellungstools und vieles mehr.

Um zu verstehen, wo dies hilfreich sein könnte, überlegen Sie, wo Sie derzeit über manuelle oder Service Desk-basierte Prozesse verfügen. Denken Sie für jeden über diese Fragen nach:

Wie oft geschieht dieser Vorgang?
Ist der Prozess langsam, fehleranfällig oder erfordert erhebliche Arbeit?
Sind diese Prozesse aufgrund eines erforderlichen Genehmigungsschritts manuell oder mangels Automatisierung?
Sind genehmigende Personen mit Quellcodeverwaltungssystemen und Pull-Anforderungsprozessen vertraut?
Was sind die Überwachungsanforderungen 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 wechseln?

Identifizieren Sie häufige, hohe Anstrengungen oder fehleranfällige Prozesse als potenzielle Ziele, um zuerst zu automatisieren.

Alles als Codemuster verwenden

Eine der schönen Dinge über Git zusätzlich zu seiner Ubiquity ist, dass es eine sichere, auditierbare Quelle von Informationen sein soll. Über die Commit-Verlaufs- und Zugriffssteuerung hinaus bieten Konzepte wie Pullanforderungen und Branch-Schutz eine Möglichkeit, bestimmte Prüfer, einen Unterhaltungsverlauf und automatisierte Prüfungen einzurichten, die vor dem Zusammenführen in die Hauptverzweigung übergeben werden müssen. In Kombination mit flexiblen Aufgabenmodulen wie den in CI/CD-Systemen gefundenen haben Sie ein sicheres Automatisierungsframework.

Die Idee hinter allem als Code besteht darin, dass Sie fast alles in eine Datei in einem sicheren Git-Repository umwandeln können. Unterschiedliche Tools oder Agents, die mit dem Repository verbunden sind, können dann den Inhalt lesen. Die Behandlung alles als Code unterstützt die Wiederholbarkeit durch Vorlagen und vereinfacht den Self-Service des Entwicklers. Sehen wir uns einige Beispiele dafür an, wie dies funktionieren kann.

Anwenden von IaC-Mustern auf jede Infrastruktur

Während IaC bei der Automatisierung der Anwendungsbereitstellung beliebt wurde, erstreckt sich das Muster auf jede Infrastruktur, Tools oder Dienste, die Sie bereitstellen und konfigurieren möchten – nicht nur diejenigen, die an eine bestimmte Anwendung gebunden sind. Beispielsweise freigegebene K8s mit Clustern, auf denen Flux installiert ist, Bereitstellung etwa von DataDog , das von mehreren Teams und Anwendungen verwendet wird, oder sogar das Einrichten Ihrer bevorzugten Tools für die Zusammenarbeit.

Die Funktionsweise ist, 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, zu Helm-Diagrammen und anderen nativen Kubernetes-Formaten). Ein Operationsteam oder eine andere Gruppe von Administratoren besitzt das Repository, und Entwickler (oder Systeme) können Pull-Anforderungen senden. Sobald diese PRs von diesen Administratoren in den Hauptzweig zusammengeführt werden, können dieselben CI/CD-Tools, die während der Anwendungsentwicklung verwendet werden, in die Verarbeitung der Änderungen aufgenommen werden. Betrachten Sie diese Abbildung, die GitHub-Aktionen 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 diese Tools auch wiederverwenden. Durch die Kombination von Tools wie Flux und Azure Service Operator können Sie außerhalb von Kubernetes erweitern:

In beiden Fällen verfügen Sie über eine vollständig verwaltete, reproduzierbare und auditierbare Informationsquelle – auch wenn das, was nicht für eine Anwendung produziert wird. Wie bei der Anwendungsentwicklung werden alle geheimen oder verwalteten Identitäten, die Sie benötigen, im Pipeline-/Workflowmodul oder in den systemeigenen Funktionen eines Bereitstellungsdiensts gespeichert.

Da die Benutzer, die die PRs machen, keinen direkten Zugriff auf diese Geheimnisse haben, bietet es Entwicklern eine Möglichkeit, Aktionen sicher zu initiieren, die sie nicht direkt berechtigt sind, sich selbst zu tun. Auf diese Weise können Sie das Prinzip der geringsten Rechte einhalten, während Entwickler weiterhin eine Self-Service-Option erhalten.

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. Im Anschluss an einen Codeansatz erhalten Sie jedoch eine Informationsquelle, um einen Bestand der bereitgestellten Infrastruktur zu synthetisieren. Möglicherweise ist Ihr Bereitstellungser auch eine gute Quelle für diese Informationen, auf die Sie tippen können. Azure-Bereitstellungsumgebungen umfassen z. B. Umgebungsnachverfolgungsfunktionen, in die Entwickler Einblick haben.

Weitere Informationen zum Nachverfolgen verschiedener Datenquellen finden Sie unter Entwerfen einer Self-Service Foundation für Entwickler.

Anwenden der Sicherheit als Code und Richtlinie als Codemuster

Während die Bereitstellungsinfrastruktur nützlich ist, ist es gleichermaßen wichtig, sicherzustellen, dass diese Umgebungen sicher sind und im Allgemeinen den Richtlinien Ihrer Organisation folgen. Dies hat zum Aufstieg des Konzepts "Policy as Code" geführt. Hier können Konfigurationsdateien in einem Quellcodeverwaltungs-Repository verwendet werden, um z. B. die Sicherheitsüberprüfung zu steuern oder Infrastrukturrichtlinien anzuwenden.

Viele verschiedene Produkte und Open Source-Projekte haben diesen Ansatz übernommen, 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 sie diese Muster unterstützen. Weitere Informationen zum Verfeinern 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. Sie 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.

Die PR wird zu einem guten Self-Service User Experience für verschiedene Prozesse – insbesondere bei den ersten Schritten. Die Prozesse erhalten natürlich die Sicherheits-, Auditierbarkeits- und Rollbackvorteile git selbst, und die beteiligten Systeme können sich auch im Laufe der Zeit ändern, ohne die Benutzererfahrung zu beeinträchtigen.

Teams als Code

Ein Beispiel dafür, dass alles als Code auf Ihre eigenen Szenarien angewendet wird, ist das Codemuster der Teams. Organisationen wenden dieses Muster an, um die Teammitgliedschaft zu standardisieren und in einigen Fällen Entwicklertools/Dienstberechtigungen über eine Vielzahl von Systemen hinweg zu standardisieren. Dieses Muster beseitigt manuelle Onboarding- und Offboarding-Service Desk-Prozesse, die von der Notwendigkeit von Systementwicklern und -betreibern abhängig sind, auf ihre eigenen Gruppen-, Benutzer- und Zugriffskonzepte zuzugreifen. Manuelle Service Desk-Prozesse sind ein potenzielles Sicherheitsrisiko, da es möglich ist, den Zugriff zu überschreiben. Wenn Sie die Teams als Codemuster verwenden, kann die Kombination aus Git- und Pull-Anforderungen Self-Service aus einer auditierbaren Datenquelle aktivieren.

Ein Beispiel für eine reife, umfangreiche Variation dieses Musters finden Sie im Blogbeitrag von GitHub zum Verwalten von Berechtigungen. GitHub hat auch ihre anspruchsvolle Berechtigungsimplementierung geöffnet, die Sie ausprobieren können – oder übernehmen. Obwohl der Blogbeitrag alle Berechtigungen von Mitarbeitern beschreibt, können Sie die Teams als Codekonzept auf schmalere Entwicklungsteamszenarien anwenden. Diese Entwicklungsteams werden möglicherweise überhaupt nicht in einem Mitarbeiter-Organigramm dargestellt und umfassen proprietäre Tools oder Dienste, die das Onboarding oder Offboarding von Teammitgliedern erschweren können.

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

In diesem Beispiel:

Jedes systembeteiligte System wurde für die Verwendung Ihres Identitätsanbieters (z. B. Microsoft Entra ID) für einmaliges Anmelden (Single Sign-On, SSO) eingerichtet.
Sie verwenden Identitätsanbietergruppen (z. B. Entra-Gruppen) über Systeme hinweg, um die Mitgliedschaft nach Rolle zu verwalten, um Komplexität zu reduzieren und die zentrale Überwachung aufrechtzuerhalten.

Hier erfahren Sie, wie dieses Muster funktioniert:

Ein zentrales, gesperrtes Git-Repository enthält eine Reihe von (in der Regel YAML)-Dateien, die jedes abstrakte Team, die zugehörigen Benutzermitgliedschaften und Benutzerrollen darstellen. Besitzer oder Genehmigende für Teamänderungen können auch an dieser Stelle gespeichert werden (z. B. über CODEOWNERS). Der Verweis auf einen Benutzer in diesen Dateien ist der Identitätsanbieter, aber dieses Repository fungiert als Wahrheitsquelle für diese Teams (aber nicht als Benutzer).
Alle Aktualisierungen dieser Dateien werden über Pullanforderungen durchgeführt. Dadurch werden Unterhaltungen und zugehörige Teilnehmer auf der Anforderung, git commit zur Überwachung zu übernehmen, verknüpft.
Leads und einzelne Benutzer können PRs zum Hinzufügen/Entfernen von Personen machen, und Entwicklerkontakte und andere Rollen können neue Teams mithilfe von PRs erstellen, die mit einer neuen Teamdatei aus einer Vorlage stammen.
Wenn eine PR im Hauptbetrieb zusammengeführt wird, aktualisiert ein CI/CD-System, das an das Repository gebunden ist, das Identitätsanbietersystem und alle nachgeschalteten Systeme entsprechend.

Insbesondere das CI/CD-System:

Verwendet die entsprechende Identitätsanbieter-System-API zum Erstellen oder Aktualisieren einer Identitätsanbietergruppe pro Rolle mit genau den Personen in der Datei (nicht mehr, nicht weniger).
Verwendet APIs für jedes nachgeschaltete System, um dieses Systemgruppierungskonzept an eine Identifizierung von Anbietergruppen für jede Rolle zu binden (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.
(Optional) Verwendet APIs für jedes nachgeschaltete System, um Berechtigungslogik zu implementieren, die an den Gruppierungsmechanismus des Systems gebunden ist.
Verwendet eine API zum Aktualisieren eines gesperrten Datenspeichers mit den Ergebnissen (einschließlich der Zuordnung der nachgeschalteten Systemteam-IDs), die dann für jedes Ihrer intern erstellten Systeme genutzt werden können. Sie können Zuordnungen auch für unterschiedliche Systemdarstellungen von Benutzer-IDs für denselben Identitätsanbieterbenutzer/-konto speichern, falls erforderlich.

Wenn Ihre Organisation bereits etwas wie entra-Berechtigungsverwaltung verwendet, können Sie möglicherweise die Verwaltung der Gruppenmitgliedschaft aus diesem Muster weglassen.

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

Manuelle oder extern ausgelöste, parametrisierte Workflows verwenden

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

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

Ihr CI-System kann es Ihnen ermöglichen, diese Workflows oder Pipelines über eine API aus Ihren eigenen Benutzeroberflächen auszulösen. Für GitHub-Aktionen ist der Schlüssel zum Ausführen dieser Arbeit die Actions-REST-API, um ein Workflow dispatch-Ereignis auszulösen, um eine Workflowausführung auszulösen. Azure DevOps-Trigger sind ähnlich, und Sie können auch die Azure DevOps Pipeline-API für Die Ausführung verwenden. Wahrscheinlich werden dieselben Funktionen in anderen Produkten angezeigt. Unabhängig davon, ob sie manuell oder über eine API ausgelöst werden, kann jeder Workflow eine Reihe von Eingaben unterstützen, indem der Workflow-YAML-Datei eine workflow_dispatch Konfiguration hinzugefügt wird. So interagieren z. B. Portal-Toolkits wie Backstage.io mit GitHub-Aktionen.

Der Workflow oder das Jobsystem Ihres CI/CD-Systems verfolgt zweifellos Aktivitäten, meldet den Status zurück und verfügt über detaillierte Protokolle, die sowohl Entwickler als auch Betriebsteams verwenden können, um zu sehen, was schief gegangen ist. Auf diese Weise hat es einige der gleichen Vorteile wie Sicherheit, Auditierbarkeit und Sichtbarkeit wie das codemuster. Beachten Sie jedoch, dass alle Aktionen, die von diesen Workflows oder Pipelines ausgeführt werden, wie eine Systemidentität (z. B. Dienstprinzipal oder verwaltete Identität in Microsoft Entra ID) auf nachgeschaltete Systeme aussehen.

Sie haben Einblick in die Personen, die Anforderungen in Ihrem CI/CD-System initiieren, aber Sie sollten beurteilen, ob dies ausreichend Informationen ist, und stellen Sie sicher, dass Ihre CI/CD-Aufbewahrungseinstellungen Ihren Überwachungsanforderungen entsprechen, wenn diese Informationen kritisch sind.

In anderen Fällen verfügen die Tools, mit denen Sie integrieren, möglicherweise über eigene Tracking-Mechanismen, auf die Sie sich verlassen können. Diese CI/CD-Tools stehen z. B. fast immer mehrere Benachrichtigungsmechanismen zur Verfügung, z. B. mithilfe eines Microsoft Teams - oder Slack-Kanals , mit dem Sie alle Personen, die eine Anforderung übermitteln, um Statusaktualisierungen zu erhalten, und der Kanal stellt einen informellen Datensatz darüber bereit, was passiert ist. Diese Workflows-Engines sind häufig bereits für die Integration mit Betriebstools konzipiert, um die Nützlichkeit dieser Muster weiter zu erweitern.

Zusammenfassend können Sie eine Automatisierung mithilfe von Dateien implementieren, die in einem Quellcodeverwaltungs-Repository gespeichert sind, dank der Flexibilität von CI/CD-Tools und deren vordefinierten Benutzererfahrungen. Um zu sehen, wie interne Entwicklerplattformen diesen Ansatz als Ausgangspunkt nutzen können, ohne im Laufe der Zeit anspruchsvollere Funktionen zu beeinträchtigen, lesen Sie Design a Developer Self-Service Foundation.

Automatisieren des Setups von Entwicklercodierungsumgebungen

Ein weiteres häufiges Problem in Technischen Systemen ist das Bootstrapping und die Normalisierung der Entwicklercodierungsumgebung. Hier sind einige der häufig auftretenden Probleme, die Sie in diesem Bereich möglicherweise hören:

In einigen Fällen kann es Wochen dauern, bis ein Entwickler zu seiner ersten Pull-Anforderung gelangen kann. Dies ist ein problematischer Bereich, wenn Sie Entwickler zwischen Feature-Crews und Projekten relativ häufig (z. B. in matrixierten Organisationen) übertragen, Auftragnehmer hochfahren müssen oder sich in einem Team befinden, das sich in einer Einstellungsphase befindet.
Inkonsistenzen zwischen Entwicklern und ihren CI-Systemen können zu häufigen Problemen bei "es funktioniert auf meinem Computer" auch bei erfahrenen Teammitgliedern führen.
Das Experimentieren und Aktualisieren von Frameworks, Laufzeiten und anderer Software kann auch vorhandene Entwicklerumgebungen unterbrechen und zu einem Verlust der Zeit führen, um genau herauszufinden, was schief gegangen ist.
Bei Entwicklungsleitern 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 Betreiber müssen außerdem Zeit damit verbringen, verwandte Rollen über die Entwicklung hinaus zu beschleunigen (Operatoren, QA, Unternehmen, Sponsoren), um zu testen, den Fortschritt zu sehen, Geschäftsrollen zu trainieren und die Arbeit zu evangelisieren, die das Team ausführt.

Teil Ihrer gepflasterten Wege

Um diese Probleme zu beheben, denken Sie an das Einrichten bestimmter Tools und Dienstprogramme als Teil Ihrer klar definierten gepflasterten Pfade. Das Einrichten von Skripts für Entwicklercomputer kann ihnen helfen, und Sie können dieselben Skripts in Ihrer CI-Umgebung wiederverwenden. Erwägen Sie jedoch die Unterstützung von containerisierten oder virtualisierten Entwicklungsumgebungen aufgrund der Vorteile, die sie bereitstellen können. Diese Codierungsumgebungen können im Voraus für die Spezifikationen Ihrer Organisation oder Ihres Projekts eingerichtet werden.

Ersatz der Arbeitsstation und Zielbestimmung von Windows

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

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

Arbeitsbereichvirtualisierung und Ziel linux

Wenn Sie auf Linux abzielen, sollten Sie eine Arbeitsbereichsvirtualisierungsoption in Betracht ziehen. Diese Optionen konzentrieren sich weniger auf das Ersetzen des Entwicklerdesktops und mehr auf projekt- oder anwendungsspezifische Arbeitsbereiche.

Vorgehensweise	Beispiele
Verwenden von in der Cloud gehosteten Containern	GitHub Codespaces ist eine cloudbasierte Umgebung für Dev-Container, die die Integration in VS Code, JetBrains IntelliJ und terminalbasierte 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 Remote-Linux-VMs verwenden. Die tunnelbasierte Option, die nicht nur mit dem Client, sondern auch mit dem webbasierten vscode.dev funktioniert.
Verwenden lokaler Container	Wenn Sie stattdessen eine lokale Dev Containers-Option bevorzugen oder zusätzlich zu einer in der Cloud gehosteten , verfügen Dev-Container über solide Unterstützung in VS Code, Unterstützung in IntelliJ und anderen Tools und Diensten.
Verwenden von in der Cloud gehosteten VMs	Wenn Sie Container zu beschränken finden, ermöglichen Ihnen SSH-Unterstützung in Tools wie VS Code oder JetBrains-Tools wie IntelliJ die direkte Verbindung zu Linux-VMs, die Sie selbst verwalten. VS Code verfügt auch hier über 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, um Entwickler lokal auf Linux abzielen zu können. Sie können eine WSL-Verteilung für Ihr Team exportieren und für alles freigeben, was eingerichtet ist. Bei einer Cloudoption können Cloudarbeitsstationsdienste wie Microsoft Dev Box auch WSL nutzen, um auf die Linux-Entwicklung abzielen zu können.

Erstellen sie richtige Startanwendungsvorlagen, die die richtige Konfiguration enthalten

Das Große an allem als Codemuster besteht darin, dass Entwickler auf den gepflasterten Pfaden, die Sie von Anfang an eingerichtet haben, beibehalten können. Wenn dies eine Herausforderung für Ihre Organisation ist, können Anwendungsvorlagen schnell zu einer kritischen Möglichkeit werden, Bausteine wiederzuverwenden, um Konsistenz zu fördern, Standardisierung zu fördern und die bewährten Methoden Ihrer Organisation zu codieren.

Zunächst können Sie etwas so einfaches wie ein GitHub-Vorlagenrepository verwenden, aber wenn Ihre Organisation einem Monorepomuster folgt, ist dies möglicherweise weniger effektiv. Sie können auch Vorlagen erstellen, die dabei helfen, etwas einzurichten, das nicht direkt mit einer Anwendungsquellstruktur verknüpft ist. Stattdessen können Sie ein Vorlagenmodul wie Cookiecutter, Yeoman oder etwas wie die Azure Developer CLI (azd) verwenden, die neben Vorlagen und vereinfachtem CI/CD-Setup auch einen praktischen Satz von Entwicklerbefehlen bietet. Da die Azure Developer CLI verwendet werden kann, um die Umgebungseinrichtung in allen Szenarien zu fördern, ist sie in Azure-Bereitstellungsumgebungen integriert, um verbesserte Sicherheit, integriertes IaC, Umgebungsnachverfolgung, Trennung von Bedenken und vereinfachtes CD-Setup bereitzustellen.

Sobald Sie über eine Reihe von Vorlagen verfügen, können Entwicklerleiter diese Befehlszeilentools oder andere integrierte Benutzeroberflächen verwenden, um ihren Inhalt für ihre Anwendungen zu gerüsten. Da Entwickler jedoch möglicherweise nicht über die Berechtigung zum Erstellen von Repositorys oder anderen Inhalten aus Ihren Vorlagen verfügen, ist dies auch eine weitere Möglichkeit, manuell ausgelöste, parametrisierte Workflows/Pipelines zu verwenden. Sie können Eingaben einrichten, wenn Ihr CI/CD-System alles von einem Repository bis zu einer Infrastruktur in ihrem Auftrag erstellt.

Bleiben Sie richtig und werden Sie richtig

Um jedoch zu skalieren, sollten diese Anwendungsvorlagen nach Möglichkeit auf zentrale Bausteine verweisen (z. B. IaC-Vorlagen oder sogar CI/CD-Workflows /Pipelines). Tatsächlich könnte es sich bei der Behandlung dieser zentralen Bausteine um eine eigene Form der richtigen Startvorlagen handelt, um einige der probleme zu lösen, die Sie identifiziert haben.

Jede dieser einzelnen Vorlagen kann nicht nur auf neue Anwendungen angewendet werden, sondern auch vorhandene Vorlagen, die Sie als Teil einer get right Campaign aktualisieren möchten, um aktualisierte oder verbesserte Richtlinien bereitzustellen. 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.

Vorlageninhalte

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

Bereich	Details
Ausreichender Beispielquellcode zum Steuern von App-Mustern, SDKs und Toolverwendung	Fügen Sie Code und Konfiguration hinzu, um Entwickler auf empfohlene Sprachen, App-Modelle und Dienste, APIs, SDKs und Architekturmuster zu lenken. Stellen Sie sicher, dass Sie Code für verteilte Ablaufverfolgung, Protokollierung und Observability mit Ihren Tools ihrer Wahl einschließen.
Erstellen und Bereitstellen von Skripts	Bieten Sie Entwicklern eine gängige Möglichkeit, einen Build und eine lokale /Sandbox-Bereitstellung auszulösen. Schließen Sie die In-IDE-/Editor-Debugkonfiguration für Ihre tools ein, die sie verwenden können. Dies ist eine wichtige Möglichkeit, wartungsschmerzende Probleme zu vermeiden und zu verhindern, dass CI/CD nicht mehr synchronisiert wird. Wenn Ihr Vorlagenmodul wie die Azure Developer CLI der Meinung 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. Tatsächlich können diese wiederverwendbaren Workflows /Pipelines eigene Vorlagen beginnen. Stellen Sie sicher, dass Sie eine Option zum manuellen Auslösen dieser Workflows in Betracht ziehen.
Infrastruktur als Coderessourcen	Stellen Sie empfohlene IaC-Konfigurationen bereit, einschließlich Verweise auf zentral verwaltete Module oder Katalogelemente , um sicherzustellen, dass alle Infrastruktureinrichtung bewährte Methoden von unterwegs aus befolgt. Diese Verweise können Auch Teams dabei helfen, richtig zu bleiben, wenn die Zeit weitergeht. In Kombination mit Workflows/Pipelines können Sie auch IaC oder EaC einschließen, um alles bereitzustellen.
Sicherheit und Richtlinie als Coderessourcen	Die DevSecOps-Bewegung hat die Sicherheitskonfiguration in Code verschoben, was sich hervorragend für Vorlagen eignet. Einige Richtlinien als Codeartefakte können auch auf Anwendungsebene angewendet werden. Fügen Sie alles von Dateien wie CODEOWNERS bis hin zur Überprüfungskonfiguration wie "dependabot.yaml " in GitHub Advanced Security hinzu. Stellen Sie geplante Workflows/Pipelineläufe für Scans bereit, die etwa Defender für Cloud zusammen mit Umgebungstestläufen verwenden. Dies ist wichtig für die Sicherheit der Lieferkette und achten Sie darauf, zusätzlich zu Anwendungspaketen und Code Containerimages zu berücksichtigen. Diese Schritte helfen Entwicklungsteams dabei, auf dem richtigen Weg zu bleiben.
Observability, Monitoring und Protokollierung	Ein Teil der Self-Service-Aktivierung bietet einen einfachen Einblick in Anwendungen, sobald sie bereitgestellt wurden. Stellen Sie über die Laufzeitinfrastruktur hinaus sicher, dass Sie setup für Observability und Überwachung einschließen. In den meisten Fällen gibt es einen IaC-Aspekt zum Einrichten (z. B. Agentbereitstellung, Instrumentierung), während es in anderen Fällen eine andere Art von Config-as-Codeartefakt sein kann (z. B. Überwachungsdashboards für Azure-App lication Insights). Fügen Sie schließlich Codebeispielcode für verteilte Ablaufverfolgung, Protokollierung und Observability mithilfe Ihrer Wahltools hinzu.
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 bereit, indem Sie Ihre bevorzugten Dienste wie Microsoft Playwright-Tests für UI- oder Azure Load Testing verwenden.
Einrichtung des Tools für die Zusammenarbeit	Wenn Ihr Problemverwaltungs- und Quellcodeverwaltungssystem Aufgaben-/Problem-/PR-Vorlagen als Code unterstützt, schließen Sie diese ebenfalls ein. In Fällen, in denen mehr Setup erforderlich ist, können Sie optional einen Workflow/eine Pipeline bereitstellen, die Ihre Systeme mit 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.