Entwerfen einer Self-Service-Foundation für Entwickler

Sobald Sie ein gutes Verständnis für Ihr Ziel für Ihre Engineering-Systeme haben, können Sie anspruchsvollere Self-Service-Erfahrungen für Entwickler erstellen. Eine Self-Service-Erfahrung für Entwickler basiert auf Konzepten, Mustern und Komponenten.

Obwohl Sie möglicherweise nicht alles benötigen, was heute in Ihrer Organisation beschrieben wird, sollten Sie diese Konzepte berücksichtigen, wenn Sie etwas benutzerdefiniertes erstellen oder verwandte Produkte auswerten. Ihr Entwickler-Self-Service Experience-Modell kann aus einer Kombination aus hausgemachten, off-the-shelf- und Open-Source-Produkten bestehen. Produkte oder Open-Source-Portal-Toolkits wie Backstage.io verwenden möglicherweise unterschiedliche Begriffe für einige Elemente des unten beschriebenen Modells, aber das Modell kann Ihnen dennoch helfen, Sie zu orientieren.

Automatisieren von Workflows, Aggregieren von Daten, Einfaches Starten und schrittweises Erweitern

Ihr Ziel ist es, Self-Service mit Schutzläufen durch kontrollierte, geregelte Aufgabenausführung und Bereitstellung zusammen mit zentraler Sichtbarkeit zu ermöglichen. Die Bereiche, auf die sie am wertvollsten sind, sind diejenigen, die entweder mühsam sind oder dinge, die der Entwickler aufgrund von Komplexität oder Berechtigungen nicht selbst erledigen kann. Dieser letzte Teil ist wichtig, damit Sie dem Prinzip der geringsten Rechte folgen können, ohne Entwickler durch einen manuellen Service Desk-Prozess zu zwingen.

Sie können ihre DevOps-Suite zwar erweitern, um diese Anforderungen zu erfüllen, aber Sie müssen wahrscheinlich mehrere Anwendungsplattformen im Laufe der Zeit unterstützen, und die spezifischen Tools und Prozesse, die sie unterstützen, müssen ebenfalls geändert werden. Das Kernproblem besteht darin, dass Ihre Standards ein bewegliches Ziel sind. Wie ein Plattformingenieur erklärte:

Die Schwierigkeiten bei der Standardisierung ... und umgangen mit "abandonware"... Die Standardisierung wird oft nicht durch mögliche Unterbrechungen automatisierter Prozesse und die zeitaufwendige Aufgabe der Identifizierung notwendiger Änderungen erreicht. - Martin, DevOps Engineer, Große Logistikgesellschaft

Der schnelle Wechsel zu einem neuen oder aktualisierten Standard ist in der Regel nicht machbar und das Verlassen vorhandener Prozesse führt zu Risiken. Ihre Organisation verwendet möglicherweise bereits mehrere DevOps-Suites oder verschiedene Kombinationen einzelner Tools und Entwicklerdienste nach Szenario. Selbst bei einem zentralen Team und einer Standardlösung ist die Variabilität unvermeidlich, da Ihre Self-Service-Anforderungen steigen. Daher sollten Sie kontrollierte Experimente ermöglichen, bei denen bestimmte Teams möglicherweise neue Technologien, Bereitstellungsstrategien usw. ausprobieren, gefolgt von absichtlicher Einführung und einem inkrementellen Rollout.

In der Regel fallen Self-Service-Erfahrungen in zwei hauptkategorien: Automatisierung und Datenaggregation.

Während die Datenaggregation eine gute Benutzererfahrung schafft, ist die Automatisierung wichtiger:

Automatisierung ist der Schlüssel und wird von allen geliebt. [Daten] Aggregation ist sekundär. – Peter, Plattform engineering Lead, multinationales Tech-Unternehmen

In Ihrer Plattform-Engineering-Reise haben Sie Probleme identifiziert, die durch Automatisierung potenziell gelöst wurden. Neben der Verringerung der kognitiven Last und des Entwickleraufwands kann die Automatisierung auch dazu beitragen, dass Anwendungen mit den besten Tools und Diensten für Vorgänge, Sicherheit und andere Rollen verbunden sind, um ihre Arbeit zu erledigen.

Wenn Sie jedoch mit mehr als einem System arbeiten, um Ihre Automatisierung voranzutreiben, ist einige Datenaggregationsebene hilfreich, um automatisierte Anforderungen und die zugehörigen Ergebnisse nachzuverfolgen. Sie können beginnen, indem Sie eine Verknüpfung mit externen Systemen herstellen, um andere Anforderungen zu erfüllen oder details zu drill-ins. Die Datenaggregation und Sichtbarkeit ist auch wichtig für die Überwachung, Governance und Reduzierung von Abfällen (Beispiel: nicht verwendete Umgebungen).

Die Automatisierung von Elementen wie der Infrastrukturbereitstellung kann mithilfe von Systemintegrationen erfolgen. Sie können aber auch einen manuellen Workflowprozess auslösen und vereinfachen, der für den Entwickler automatisiert aussieht. Dies ist in den frühen Phasen Ihrer Plattform nützlich, für neue Produkte, die Sie in Ihr Ökosystem integrieren, oder in Bereichen, die Sie nicht haben oder nicht automatisieren können, mithilfe eines Systems (z. B. Softwarelizenzzuweisung). Mit dem richtigen Design können Sie mit einem manuellen Prozess beginnen, der durch etwas wie Power Automate erleichtert wird, das Sie im Laufe der Zeit zu einem vollständig automatisierten Ablauf wechseln. Entwerfen Sie also von Anfang an eine Automatisierung.

Beginnen Sie einfach, indem Sie vorhandene Investitionen wie Ihre Engineering-Systeme oder ein internes Portal wiederverwenden, dann CLIs, grundlegende Webseiten oder sogar Power Pages, Power BI oder Microsoft Fabric-Dashboards erstellen und bei Bedarf erweitern. Wenn Sie eine konsistente API verwenden, die dann verwendet wird, können Sie mehrere Schnittstellen im Laufe der Zeit unterstützen, während sich Ihre Anforderungen und Einstellungen ändern.

Self-Service-Plattformkomponenten für Entwickler: API, Graph, Orchestrator, Anbieter und Metadaten

Berücksichtigen Sie die Grundlagen von Self-Service für Entwickler:

Wie die Abbildung zeigt, bilden die folgenden Komponenten den Kern des Konzepts einer Self-Service Foundation für Entwickler:

Mit diesen grundlegenden Komponenten können Sie unterschiedliche Bausteine im Laufe der Zeit verwenden und austauschen.

Muss ich all dies erstellen, um zu beginnen?

Nein Zunächst ist dies ein konzeptionelles Modell, mit dem Sie darüber nachdenken können, was eine Stiftung wie diese tun sollte, sobald sie abgeschlossen ist. Zweitens sind die Implementierungsspezifischen hier weniger wichtig, da die Entwicklerplattform-API Zu Ihrer wichtigsten Schnittstelle wird. Ihre anfängliche Implementierung kann mit der Verwendung von Schnittstellen und Klassen in Ihrem Code für die verschiedenen Ebenen beginnen, die in anderen Produkten beschrieben oder gemischt werden. Sie könnten auch Aspekte weglassen, da Ihre Kundenentwicklung Ihnen sagt, dass sie einfach eine niedrigere Priorität hat. Beginnen Sie mit dem, was Sie haben und wachsen.

Entwicklerplattform-API

Sie sollten eine Entwicklerplattform-API definieren, die als Vertrag Ihres Systems fungiert. Die API wird von verschiedenen Benutzeroberflächen verwendet, um den Datenzugriff oder die Laufwerksbereitstellung und andere Aktionen zu ermöglichen.

Diese API fungiert als wichtige Authentifizierungs- und Sicherheitsebene, indem der Zugriff auf unformatierte zugrunde liegende APIs in anderen Systemen auf spezifischere, kontrollierte Daten und Vorgänge beschränkt wird. Die API bietet Zugriff auf seine eigene Darstellung eines Benutzerprofils, der allgemeinen Rolle eines Benutzers innerhalb der Plattform (Teammitglied, Administrator usw.) und systembezeichner des primären Identitätsanbieters. Weitere Informationen finden Sie unter "Benutzer und Teams".

Entwicklerplattformanbieter

Aufgrund der Breite einer internen Entwicklerplattform können Sie Systeme erstellen oder identifizieren, die einem erweiterbaren Anbietermodell folgen, um Funktionen in die API einzuführen. Die Idee besteht darin, dass wichtige Funktionen wie Automatisierung und Datenaggregation durch Interaktion mit austauschbaren Komponenten mit gut definierten Schnittstellen bereitgestellt werden. Diese lose Kopplung hilft Ihnen dabei, inkrementell zu verkabeln und die Wartungsfreundlichkeit zu verbessern, da Sie die Funktionalität unabhängig von der restlichen Basis testen können.

Es ist auch eine wichtige Möglichkeit, eine skalierbare innere Quell-Mentalität für Ihre Plattform zu ermöglichen. In der Regel können inneren Beschaffungsbemühungen rund um das Plattform engineering aufgrund von Herausforderungen bei der laufenden Wartung keine Zugkraft gewinnen. Andere Teams sind möglicherweise bereit, Funktionen mitzuwirken, sind aber weniger wahrscheinlich bereit, etwas im Kern Ihrer Plattform zu pflegen und zu testen. Umgekehrt verfügt jedes zentralisierte Team über eingeschränkte Kapazität, um mitgewirkten Code aufrechtzuerhalten oder sogar Pull-Anforderungen zu überprüfen. Das Konzept eines Entwicklerplattformanbieters entschärft diese Spannung, indem unabhängig geschriebener Code in Ihrer Self-Service-Foundation für entwicklerinterne Funktionen "plug in" integriert werden kann. Obwohl Sie sorgfältig verwalten sollten, welche Anbieter Sie verwenden, überprüfen Sie jeden Anbietercode, und beschränken Sie die Fläche, auf die ein bestimmter Anbieter in Ihrer Entwicklerplattform zugreifen kann, ein austauschbarer Ansatz kann Ihnen helfen, mehr zu erledigen, indem Sie den Aufwand für einen breiteren Teil der Organisation skalieren.

Schlüsselkonzepte für Entwicklerplattformanbieter

Entitäten

Das Konzept einer Entität ist etwas, das ein Entwickler oder ein anderes System in Ihrer internen Entwicklerplattform benötigt, um nachzuverfolgen, zu aktualisieren, zu präsentieren oder zu handeln. Entitäten können Beziehungen zueinander haben, die, wenn sie zusammengenommen werden, ein Diagramm bilden, das wichtige Informationen zu Teilen Ihrer internen Entwicklerplattform bereitstellt. Entwicklerplattformanbieter können dann Entitäten ausgeben, um Kernfunktionen zu aktivieren, einschließlich:

• Auffinden von extern bereitgestellten Ressourcen/Umgebungen oder verfügbaren APIs für die Ermittlung und Verwendung
• Verfügbarmachen von Beziehungen für Abhängigkeitsanalyse, Auswirkungsanalyse, Ermittlung usw.
• Surfacing Maintainer/Ownership Information for Discovery and Collaboration
• Mehr Daten für die Verwendung in Benutzeroberflächen

Die Kapselung dieser Funktionalität in eine gut definierte Entwicklerplattformanbieterschnittstelle vereinfacht die Integration und Tests, ermöglicht eine unabhängige Bereitstellung und ermöglicht Entwicklern außerhalb des primären internen Entwicklerplattformteams, Anbieter beizutragen und zu verwalten. Dies ist in großen oder divisionalen Organisationen wichtig, in denen nicht jedes Tool, jeder Dienst oder jede Plattform zentral verwaltet wird, aber die breitere Organisation möchte weiterhin Funktionen teilen. Selbst wenn Sie diesen Weg anfangs nicht hinunterschreiten, ist es etwas, über das Sie langfristig nachdenken sollten.

Allgemeine Eigenschaften

Jede Entität sollte über eine Reihe allgemeiner Eigenschaften verfügen, damit sie von der Foundation verwaltet werden können. Einige zu berücksichtigende Eigenschaften umfassen:

• Eindeutiger Bezeichner
• Name
• Ursprungsanbieter
• Optionale Zuordnungen zu:
  • zuständige Benutzer
  • Besitzerteam
  • Andere Entitäten

Die Benutzer- und Teameigenschaften sind aus drei Gründen wichtig: rollenbasierte Zugriffssteuerung (RBAC), Ermittlung und Datenaggregation (z. B. Zusammenfassungen auf Teamebene). Das Erstellen von RBAC von Anfang an ist für die Sicherheit von entscheidender Bedeutung und die Entwicklung Ihrer internen Entwicklerplattform im Laufe der Zeit. Bei der Entwicklung handelt es sich um einen Teamsport, der herausfindet, mit wem man über eine Entität sprechen soll, schnell kritisch für die Wiederverwendung, Unterstützung und Inneres werden.

Allgemeine und anbieterspezifische Entitäten

Sie sollten auch in der Lage sein, eine Reihe allgemeiner normalisierter Entitäten einzurichten, die von mehreren Anbietern ausgegeben werden können. Zum Beispiel:

• Umgebungen
• Ressourcen
• APIs
• Repositorys
• Komponenten
• Extras

Diese sollten in der Regel auf hoher Ebene erfolgen, z. B. im C4-Modellkontext oder auf der höchsten Ebene von Komponentendiagrammen. Für eine Umgebung müssen Sie z. B. nicht die Details der internen Infrastrukturtopografie einschließen: Sie benötigen nur genügend Informationen, um verschiedene konzeptionelle Umgebungen von mehreren Anbietern in derselben UX auflisten und zuordnen zu können. Die Entität kann auf niedrigere Detailebenen außerhalb des Systems zeigen, anstatt zu versuchen, alles zu nutzen. Diese bieten Ausgangspunkte für die Ermittlung, die für die Datenaggregation im Laufe der Zeit von zentraler Bedeutung sind.

Andere sind für einen bestimmten Anwendungsfall oder Anbieter spezifisch, daher sollten Sie überlegen, wie Sie eine wachsende Gruppe von Entitätstypen im Laufe der Zeit berücksichtigen können.

Vorlagen

Das Konzept einer Vorlage in diesem Kontext unterscheidet sich von der Idee der Entitäten darin, dass sie eine Aktion vorantreiben möchten. Beispielszenarien sind die Infrastrukturbereitstellung, das Erstellen eines Repositorys und andere lange ausgeführte Prozesse. Diese Vorlagen sollten auch über erweiterbare Entwicklerplattformanbieter verfügbar sein und die gleichen gemeinsamen Eigenschaften wie Entitäten unterstützen – einschließlich Entitätszuordnungen.

Sie können jedoch auch erforderliche Eingaben definieren, unabhängig davon, ob das System oder der Benutzer angegeben wurde, die zum Ausführen der Aktion erforderlich sind. Diese können von einem anderen Bereich wie dem Benennen der Ressource bis hin zu optionalen Ergänzungen reichen.

Beispiele für Vorlagen sind:

• Infrastructure-as-Code(IaC)-Vorlagen
• Anwendungsvorlagen (Start rechts) oder Vorlagenrepositorys
• Erstellen von Pipeline-/Workflowvorlagen
• Bereitstellungspipeline/Workflowvorlagen
• Parametrisierte Skripts
• Parametrisierte Power Automate-Flüsse (Beispiel: ausgelöster Cloudfluss einer HTTP-Anforderung)
• E-Mail-Vorlagen

Wie Entitäten können Vorlagen anbieterspezifische Eigenschaften enthalten.

Jede Vorlage weist möglicherweise eine andere Darstellung auf, die für den Anbieter eindeutig ist. Diese reichen möglicherweise von Terraform- oder ARM-Vorlagen bis hin zu Helm-Diagrammen, parametrisierten GitHub-Aktionen-Workflows oder Azure-Pipelines, einfachen Skripts oder benutzerdefinierten Formaten.

Die tatsächlich zugrunde liegenden Vorlagendetails müssen nicht unbedingt zentral gespeichert werden. Sie könnten in verschiedenen Repositorys, Registern oder Katalogen vorhanden sein. Sie können beispielsweise GitHub-Vorlagenrepositorys für Ihre Anwendungsvorlagen verwenden, während Ihre IaC-Vorlagen in einem eingeschränkten Katalogrepository vorhanden sein können, auf das Entwickler nur indirekt über Azure-Bereitstellungsumgebungen zugreifen können. Andere IaC-Vorlagen können in einer OCI Artifact Registry wie Helm-Diagrammen gespeichert werden. In anderen Fällen kann es sich bei der Vorlage um einen Verweis auf einen parametrisierten HTTP-Endpunkt handeln. Ein Entwicklerplattformanbieter sollte genügend Informationen zu den einzelnen Vorlagentypen bereitstellen, damit auf sie verwiesen werden kann, und alle Optionen, die für die Verwendung in benutzeroberflächen verfügbar gemacht werden. Aber die Vorlagen selbst können an der natürlichsten Stelle für Ihre Anwendungsfälle untergebracht werden.

Plattformingenieure oder Experten in einem bestimmten Bereich schreiben Vorlagen und teilen sie dann für die Wiederverwendung mit Entwicklungsteams. Durch die Zentralisierung der Verwendung dieser Vorlagen über ein System können Entwickler Self-Service-Dienste erstellen und Schutzschienen erstellen, die die Einhaltung von Organisationsstandards oder -richtlinien unterstützen. Mehr dazu, wenn wir den Entwicklerplattform-Orchestrator in ein bisschen abdecken.

Das Diagramm der Entwicklerplattform

Sie können sich ein Entwicklerplattformdiagramm als etwas vorstellen, mit dem Sie Entitäten und Vorlagen aus mehreren Anbietern einem durchsuchbaren Diagramm zuordnen können. Die tatsächlichen Daten für die Entitäten müssen jedoch nicht unbedingt direkt in einer diagrammspezifischen Datenbank gespeichert werden. Stattdessen können Interaktionen mit Anbietern zusammen mit benötigten Metadaten zwischengespeichert werden, damit sie alle zusammenpassen.

Das Diagramm ist leistungsfähig, wenn es mit gemeinsamen Entitäten verwendet wird, die mehrere Anbieter beitragen könnten. Eine Liste der APIs kann z. B. aus einem Produkt wie Azure API Center stammen, Sie möchten aber auch automatisch in Bereitstellungen und Umgebungen von Ihren kontinuierlichen Bereitstellungssystemen feeden. Im Laufe der Zeit können Sie zwischen verschiedenen Bereitstellungssystemen wechseln oder sogar mehrere Bereitstellungssysteme unterstützen. Solange jedes Bereitstellungssystem über einen Entwicklerplattformanbieter verfügt, sollten Sie dennoch in der Lage sein, die Zuordnung zu erstellen.

Jede Ihrer Benutzeroberflächen, die aus diesem Diagramm erstellt werden, kann dann eine gemeinsame API nutzen, um Ermittlung, Suche, Governance und vieles mehr zu ermöglichen. Ein Entwicklerplattform-Orchestrator kann dann dieses Diagramm nutzen, sodass alle Aktionen, die von einem Entwicklerplattformanbieter ausgeführt werden, automatisch Entitäten beitragen, die für dieselbe API verfügbar sind.

Entwicklerplattform-Orchestrator

Ein Entwicklerplattform-Orchestrator ermöglicht Entwicklern oder Systemen das Erstellen von Anforderungen zum Ausführen einer Aktion mithilfe einer Vorlage. Diese Aktionen werden nicht selbst ausgeführt, sondern stattdessen mit einem Aufgabenmodul, einem Workflowmodul oder einem anderen Orchestrator koordiniert. Es ist eines der kritischen Teile, die Sie sicher sein möchten, ist ein Teil Ihrer Self-Service-Foundation. Es ermöglicht Entwicklern, Anforderungen mit einer Vorlage zu erstellen oder eine Aktion ohne direkte Berechtigung auszuführen. Im Gegensatz zum Konzept von CI oder CD müssen diese Aktionen nicht mit dem Anwendungsquellcode zusammenhängen.

Sie können GitHub-Aktionen, Azure-Pipelines oder ein anderes Workflowmodul als Orchestrator verwenden. Dies ist ein vernünftiger Ausgangspunkt, aber Möglicherweise möchten Sie ein bisschen Abstraktion durchführen, damit verschiedene Arten von Vorlagen unterschiedliche zugrunde liegende Engines verwenden können. Dies kann aus einigen Gründen nützlich sein:

• Zunächst möchten Sie wahrscheinlich unterschiedliche Workflow- und Aufgabenausführungsmodule im Laufe der Zeit auswählen können, ohne einen Flashschnitt durchführen zu müssen. Indem Sie mehr als ein Modul zulassen, können Sie die Migration im Laufe der Zeit oder einfach die Verwendung des neuen Moduls zu neuen Aktionen durchführen, ohne ältere Zunutze zu haben.
• Einige Prozesse, die Sie bei der Orchestrierung unterstützen möchten, erfordern möglicherweise zunächst manuelle Schritte, auch wenn Sie diese später vollständig automatisieren möchten.
• Andere Aktionen können Rollen außerhalb des Entwicklerteams als Ziel festlegen, z. B. Die Kontenzahl oder ein Lizenzadministrator. Low-Code-Engines wie Power Automate funktionieren häufig gut für diese Rollen.
• Andere Aktionen können über einfache HTTP-Anforderungen verarbeitet werden, bei denen das Drehen eines so fähigen Vorgangs wie GitHub-Aktionen oder Azure-Pipelines nicht erforderlich oder kosteneffizient ist, um skaliert zu werden.

Glücklicherweise kann die Erweiterung der Idee eines Entwicklerplattformanbieters, um Trigger- und Tracking-Automatisierungsschritte abzudecken, diese erforderliche Abstraktion bieten. Betrachten Sie die folgende Abbildung:

Hier ist das allgemeine Konzept:

• Vorlagen können optional einen Satz von Eingaben angeben, die der Benutzer eingeben kann. Wenn ein Entwickler eine bestimmte Aktion auslöst, wählen sie eine Vorlage aus (auch wenn dies nicht beschrieben wurde), und geben Eingaben ein.
• Ein Verweis auf die vorlagenbezogenen Eingaben wird zu einer Anforderung in der Entwicklerplattform-API.
• Sobald eine Anforderung übermittelt wurde, beginnt ein Anforderungsrouting und eine Verarbeitungskomponente innerhalb des Orchestrators mit der Nachverfolgung des Lebenszyklus der Anforderung. Die Anforderungsrouting- und Verarbeitungskomponentesvorlage wird in der Anforderung an den Entwicklerplattformanbieter weitergeleitet, bei dem die Vorlage stammt.
• Der Entwicklerplattformanbieter führt dann die entsprechenden Schritte für die Implementierung aus.
• (Optional) Der Entwicklerplattformanbieter aktualisiert den Anforderungsstatus, während er die Aktion ausführt.
• Sobald die Anforderung erfüllt ist, kann der Entwicklerplattformanbieter eine Reihe von Entitäten zurückgeben, die im Entwicklerplattformdiagramm hinzugefügt/aktualisiert werden sollen. Hierbei kann es sich um anbieterspezifische oder gemeinsame Entitäten handeln.

Optional können Entwicklerplattformanbieter die Entwicklerplattform-API direkt aufrufen, um weitere Entitäten als Eingaben abzurufen oder sogar eine andere verwandte Aktion anzufordern.

Wählen Sie einen Entwicklerplattformanbieter aus, der eine allgemeine Aufgabe oder ein Workflowmodul verwendet. Genauer gesagt möchten Sie, dass etwas überbrücken soll, was Sie als Teil von Apply Software Engineering-Systemen zusammensetzen. Ein allgemeines Workflow- oder Aufgabenausführungsmodul, in das investiert werden soll, ist ein CI/CD-System.

Beispiel für GitHub-Aktionen oder Azure-Pipelines

Sehen wir uns kurz an, wie ein GitHub-Aktionen oder Azure-Pipelines als Entwicklerplattformanbieter funktionieren würde.

Für GitHub-Aktionen ist der Schlüssel für diese Arbeit, dass ein Entwicklerplattformanbieter eine Verbindung mit der angegebenen GitHub-Instanz herstellen und die Actions-REST-API verwenden kann, um ein Workflow dispatch-Ereignis auszulösen, um eine Workflowausführung auszulösen. Jeder Workflow kann eine Reihe von Eingaben unterstützen, indem der Workflow-YAML-Datei eine workflow_dispatch Konfiguration hinzugefügt wird. 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.

Diese Workflows oder Pipelines müssen sich nicht in Anwendungsquellcoderepositorys befinden. Das Konzept wäre es, diese Tatsache zu nutzen, um etwas wie folgt zu tun:

• Plattformingenieure oder DevOps-Teammitglieder können die Workflows/Pipelines in einem oder mehreren zentralen Repositorys verwalten, auf die Entwickler selbst keinen Zugriff haben, aber der Entwicklerplattformanbieter ist für die Verwendung eingerichtet. Dieses Repository kann Skripts und IaC-Codeausschnitte enthalten, die von den Workflows/Pipelines verwendet werden.
• Damit diese Workflows/Pipelines mit dem entsprechenden nachgeschalteten System interagieren können, können Ops oder andere Mitglieder Ihres Plattform-Engineering-Teams die erforderlichen Geheimnisse im zentralen Repository hinzufügen. Ausführliche Informationen dazu finden Sie in der Dokumentation zu GitHub-Aktionen und Azure DevOps , oder Sie können die Geheimen mithilfe von Azure Key Vault zentralisieren.
• Diese Workflows/Pipelines können dann einem Modell folgen, in dem sie alle resultierenden Entitäten als Build-/Bereitstellungsartefakt (GitHub-Dokumente, Azure DevOps-Dokumente) veröffentlichen.
• Während einer Ausführung kann der Entwicklerplattformanbieter dann den Status des Workflows/der Pipeline überwachen und den Lebenszyklusstatus im Orchestrator aktualisieren, bis er abgeschlossen ist. Beispielsweise können Sie Web-Hooks mit GitHub-Aktionen und Dienst-Hooks mit Azure-Pipelines verwenden, um Updates nachzuverfolgen.
• Nach Abschluss des Vorgangs kann der Anbieter das veröffentlichte Artefakt nach Bedarf für die Aufnahme in Entwicklerplattformdiagramm nutzen.

Schließlich können Sie diesen Entwicklerplattformanbieter einrichten, um eine Reihe von Vorlagen in das Entwicklerplattformdiagramm auszugeben, die auf das entsprechende Repository und die entsprechende Workflow/Pipeline verweisen, sowie Eingaben für eine bestimmte Aufgabe.

Das Große an der Verwendung eines CI/CD-Systems besteht darin, dass sie häufig für die Unterstützung der Ausführung beliebiger CLIs eingerichtet sind, sodass Sie keine erstklassige, einzigartige Integration für alles benötigen, was Sie tun. Sie können diese im Laufe der Zeit nach Bedarf hinzufügen.

Ein Großteil der in diesem Beispiel beschriebenen Elemente wendet an, wie andere Anbietertypen funktionieren könnten. Es ist auch wichtig zu beachten, dass die Verwendung von GitHub-Aktionen oder Azure-Pipelines in diesem Kontext nicht erfordert, dass Sie sie auch für Ihre tatsächlichen CI/CD-Pipelines verwenden.

Weitere Beispiele

Hier sind einige Beispiele für andere Arten von Entwicklerplattformanbietern, die Vorlagen verarbeiten können.

Obwohl Sie möglicherweise nicht alle diese Anbieter starten müssen, können Sie sehen, wie die Erweiterbarkeit durch einen Entwicklerplattformanbieter Ihre Automatisierungsfunktionen im Laufe der Zeit vergrößern kann.

Benutzer und Teams

Plattformtechnik ist inhärent eine Multisystemaffäre, daher ist es wichtig zu planen, wie eine Self-Service-Foundation die anspruchsvolleren Probleme mit der Integration dieser Systeme bewältigen sollte. Hier ist eine Strategie für die Bewältigung allgemeiner Herausforderungen mit Identität, Benutzern und Teams.

Einrichten des Konzepts eines Teams über eine einzelne Identitätsanbietergruppe hinaus

Während Ihre Plattformentwicklungsreise fortgesetzt wird, werden Sie wahrscheinlich feststellen, dass Identitätsanbietergruppen ideal für die Verwaltung der Mitgliedschaft sind, aber dass mehrere Gruppen wirklich zusammenkommen müssen, um das Konzept eines Teams für die rollenbasierte Zugriffssteuerung (RBAC) und die Datenaggregation zu bilden.

Im Kontext des Plattform engineering definieren wir ein Team als eine Reihe von Personen in verschiedenen Rollen, die zusammenarbeiten. Bei der Datenaggregation ist die Idee eines Multi-Role-Teams für die Power Discovery und roll-up-Informationen an Orten wie Berichtsdashboards von entscheidender Bedeutung. Andererseits ist eine Gruppe ein allgemeines Identitätsanbieterkonzept für eine Gruppe von Benutzern und ist mit der Idee konzipiert, mehrere Personen zu einer bestimmten Rolle hinzuzufügen, anstatt anders herum. Mit RBAC kann ein Team daher über unterschiedliche Rollen mit mehreren Identitätsanbietergruppen in Beziehung stehen.

Die Quelle Ihrer Teamdaten kann von einigen verschiedenen Orten stammen. Wenn Sie beispielsweise die Teams als Codemuster (TaC) verwenden, kann ein Entwicklerplattformanbieter auf Dateiänderungen in einem Repository achten und diese in einem Benutzerprofil- und Teammetadatenspeicher zwischenspeichern. Sie können auch direkt in ein Azure Dev Center-Projekt integriert werden, das bereits über diese zentralen RBAC-Konstrukte verfügt.

Einrichten eines Modells für die Integration mit nachgeschalteten Systemen auf Team- oder Benutzerebene

Während einige Entwickler- und Operationstools/-Dienste Identitätsanbieterkonzepte direkt integrieren und verwenden, werden viele dies in ihre eigene Darstellung einer Gruppe oder eines Benutzers (sogar mit SSO) abstrahieren. Über die Aktivierung des Zugriffs über Tools hinaus kann diese Realität auch Probleme bei der Datenaggregation darstellen. Insbesondere können Sie feststellen, dass APIs im nachgeschalteten System ihre eigenen Bezeichner anstelle von Identitätsanbieter-IDs verwenden (Beispiel: Die Objekt-ID in Entra-ID wird nicht direkt verwendet). Dadurch wird das Filtern und Zuordnen von Daten auf Benutzer- oder Teamebene erschwert, es sei denn, Sie können zwischen verschiedenen IDs zuordnen.

Adressieren von Unterschieden auf Team- und Gruppenebene

Muster wie TaC können es Ihnen ermöglichen, Beziehungen zwischen den Team- oder Gruppenbezeichnern jedes Systems zu speichern und darauf zuzugreifen, sodass Sie diese zuordnen können. Um eine Zusammenfassung zu erhalten, wird ein sicheres, überprüfbares Git-Repository zur Quelle eines Teams, und PRs stellen eine kontrollierte Benutzeroberfläche bereit, um Aktualisierungen vorzunehmen. CI/CD-Systeme können dann nachgelagerte Systeme aktualisieren und die zugehörigen Bezeichnerbeziehungen für das verwendete Team beibehalten.

So können beispielsweise die folgenden Beziehungen in API-Aufrufen gespeichert werden:

Wenn Sie eine andere Datenquelle als Dateien in einem Repository Ihrer Teams verwenden möchten, kann dieses allgemeine Konzept mit dem Entwicklerplattform-Orchestrator angewendet werden, um dasselbe zu erreichen. Unter diesem Modell kann ein Entwicklerplattformanbieter für die Quelle der Teamdaten ein Teamupdateereignis auslösen, das alle anderen Anbieter erhalten und entsprechend bearbeiten.

Beheben von Herausforderungen bei der Benutzer-ID

Eine weitere verwandte Herausforderung für den Datenzugriff und die Aggregation sind Benutzer-ID-Unterschiede. Wie im Teamfall können Sie nicht davon ausgehen, dass die systemeigene ID (z. B. Objekt-ID für Entra-ID) eine bestimmte API unterstützt, wenn Sie eine System-zu-System-Integration verwenden, um Daten zu einem Benutzer abzufragen. Hier kann das Speichern einer Zuordnung für eine Benutzer-ID, die über die Entwicklerplattform-API auf Daten zugreift, hilfreich sein. Beispiel: GitHub:

Wenn Sie für jedes System einen Nachschlagevorgang einer Benutzer-ID über eine API ohne Benutzertoken durchführen können, kann ein bestimmter Entwicklerplattformanbieter diese Zuordnung automatisch generieren. In einigen Fällen kann dies kompliziert werden, da Sie diesen Vorgang möglicherweise in Massen ausführen und die Ergebnisse zwischenspeichern müssen, um die Leistung aufrechtzuerhalten.

Zurückgreifen auf die Verwendung mehrerer Benutzertoken

In Situationen, in denen Anbieter ohne Möglichkeit auf Benutzer-ID-Übersetzung zugreifen müssen, die funktionieren würde, kann die Entwicklerplattform-API eingerichtet werden, um mehrere Benutzertoken zu verwalten. Zum Beispiel:

• Die Entwicklerplattform-API kann einen Cache von anbieterspezifischen Benutzertoken für die Verwendung mit downstream-Systemen unterstützen.
• Alle Interaktionen mit einem bestimmten Anbieter, der von der API ausgelöst wird, enthalten ggf. das Benutzertoken des Anbieters.
• Um den Fall zu behandeln, in dem kein Benutzertoken verfügbar war, löste der Anbieter einen OAuth-Fluss aus, um einen abzurufen.
• Zunächst übergibt die Entwicklerplattform-API einen Authentifizierungs-URI für einen OAuth-Fluss mit einem Umleitungs-URI, der an den Anbieter übergeben wurde. Der übergebene URI enthält einen Nonce/einmaligen Code.
• Die API gibt dann eine "nicht authentifizierte" Antwort mit dem URI zurück.
• Jede UX kann dann diesen URI verwenden, um den entsprechenden Authentifizierungsfluss in einem Browser zu steuern.
• Sobald die Umleitung erfolgt, erhält die Entwicklerplattform das erforderliche Benutzertoken und speichert es für zukünftige Verweise zusammen mit der Benutzer-ID zwischen.
• Der Client könnte dann den API-Aufruf wiederholen, was dann erfolgreich wäre.

Dieses Konzept beschreibt eine Möglichkeit zum Umgang mit komplizierter Authentifizierung, da Sie IDs nach Möglichkeit wiederverwenden können und keine separaten Umleitungs-URIs pro downstreamem System beibehalten müssen.

Verwenden von kontextabhängigen Deep-Links zu Tools und Berichterstellungssystemen

Bis zu diesem Punkt haben wir über den Automatisierungsaspekt des Problemraums gesprochen. Dies allein kann weit gehen, da Ihre Benutzeroberfläche Werte in den entitäten verwenden kann, die während der Automatisierung zurückgegeben werden, um Deep-Links zu anderen Systemen für das Team zu erstellen.

Selbst wenn keine Automatisierungsbezogene, können Entwicklerplattformanbieter jede Art von Entitätsbedarf ausgeben. In der Regel möchten Sie jedoch nicht alle detaillierten Daten auf Ihrer gesamten internen Entwicklerplattform in Ihr Entwicklerplattformdiagramm integrieren. Dashboards in Observability-Lösungen wie Grafana, Prometheus, DataDog oder Code Intelligence in Produkten wie SonarQube und nativen Funktionen in DevOps-Suites wie GitHub und Azure DevOps sind alle sehr fähig. Stattdessen besteht der beste Ansatz häufig darin, Deep-Links zu diesen anderen Systemen zu erstellen. Ihre Entitäten können ausreichende Informationen bereitstellen, um Links zu erstellen, ohne direkt detaillierte Informationen wie Protokollinhalte zu enthalten.

Für Fälle, in denen Sie aggregierte und zusammengefasste Daten über Tools hinweg benötigen oder benutzerdefinierte Metriken steuern müssen, können Berichterstellungslösungen Power BI oder Microsoft Fabric Ihr nächster Anrufport sein. Zum Zusammenführen in Teamdaten können Sie entweder eine Verbindung mit der Datenbank Ihrer Foundation herstellen oder eine Entwicklerplattform-API durchlaufen. Wie in "Plan" und "Priorisierung" beschrieben, kann beispielsweise ein benutzerdefiniertes Dashboard den Erfolg Ihrer internen Entwicklerplattform messen.

Seien Sie selektiv mit jeder zusätzlichen Erfahrung, die Sie erstellen

Es kann zwar ansprechend sein, vorhandene Funktionen in etwa einem gängigen Portal neu zu erstellen, denken Sie jedoch daran, dass Sie sie auch beibehalten müssen. Dies ist der Bereich, in dem das Folgen einer Produkt-Denkweise wichtig ist. Dashboardstilschnittstellen sind leicht zu verstehen und zu verstehen, aber Ihre Entwickler finden möglicherweise an anderer Stelle mehr Wert.

Das Modell hier ermöglicht es Ihnen, aggregierte Daten im Entwicklerplattformdiagramm zu verwenden, um benutzerdefinierte Benutzeroberflächen zu erstellen. Entitäten sollten über integrierte Unterstützung verfügen, damit sie mit einem Benutzer oder Team verbunden werden können. Auf diese Weise kann Ihre Entwicklerplattform-API die Ausgabe (zusammen mit der Indizierung und Zwischenspeicherung) einschränken.

Selbst wenn Sie jedoch anstelle eines Deep-Links benutzerdefinierte UX erstellen müssen, ist das Abrufen aller Daten in Ihr Entwicklerplattformdiagramm in der Regel immer noch nicht der beste Ansatz. Betrachten Sie beispielsweise eine Situation, in der Sie Möglicherweise Protokolle in Ihrer UX anzeigen möchten, die bereits über ein gut definiertes und verwaltetes Zuhause verfügen. Verwenden Sie Informationen in den zugehörigen Entitäten, um Ihre UX dabei zu unterstützen, Informationen direkt aus nachgelagerten Systemen zu sammeln.

Um zu beginnen, müssen Sie möglicherweise eine System-zu-System-Integration verwenden, um eine Verbindung herzustellen, aber nachdem Sie eines der in Benutzern und Teams beschriebenen Modelle implementiert haben, können Sie bei Bedarf alle gespeicherten nachgelagerten Benutzer-/Team-IDs oder Benutzerauthentifizierungstoken verwenden.

Nachfolgend finden Sie einige Beispiele für allgemeine Erfahrungen, die Sie berücksichtigen sollten:

Benutzeroberflächen

Unterschiedliche Rollen in Ihrer Organisation verfügen über Tools oder Dienste, die einen Mittelpunkt der Schwerkraft für ihre tägliche Arbeit darstellen. Der Pull dieser Systeme kann es schwierig machen, neue Benutzeroberflächen außerhalb dieser Schwerkraftzentren zu erreichen, um zugkräftig zu werden. In einer perfekten Welt können Entwickler, Vorgänge und andere Rollen weiterhin in einer Umgebung arbeiten, die für sie sinnvoll ist – häufig auch diejenigen, die sie bereits verwenden.

Dies ist eine gute Idee, wenn Sie mehrere Benutzeroberflächen planen, während Sie auf Ihrer Plattform-Engineering-Reise vorankommen. Dies kann auch die Möglichkeit bieten, einfach zu beginnen, Wert zu beweisen und zu komplexeren Schnittstellen zu wachsen, da die Notwendigkeit entsteht.

Integrieren Sie das, was Sie haben.

Wenn Sie die Artikel " Software Engineering-Systeme anwenden" und "Anwendungsplattform verfeinern" gelesen haben, haben Sie wahrscheinlich die Systeme identifiziert, die Sie weiterhin verwenden möchten. Bewerten Sie in beiden Fällen, ob Sie das, was Sie haben, verbessern und erweitern können, bevor Sie mit dem Erstellen neuer Erfahrungen von Grund auf neu beginnen. (Fragen Sie sich selbst, reagieren die Benutzer besser auf eine andere neue Benutzeroberfläche oder eine verbesserte Version von etwas, das sie jetzt haben?)

Einige der Tools, Dienstprogramme oder Web-Apps, die Sie weiterhin verwenden möchten, sind benutzerdefinierte, und dies sind gute Kandidaten für die Verbesserung. Vergessen Sie jedoch nicht, darauf zu achten, ob Ihre bevorzugten Tools und Dienste über ein Erweiterbarkeitsmodell verfügen, das Sie verwenden können. Sie profitieren viel davon, dass Sie dort beginnen. Dadurch können Wartungs- und Sicherheitsprobleme beseitigt werden, und Sie können sich auf das Problem konzentrieren, das Sie lösen möchten.

So können Sie beispielsweise die folgenden Oberflächen erweitern, die Sie bereits verwenden:

• Editoren und IDEs.
• Ihre DevOps-Suite.
• AUCH CLIs sind zunehmend erweiterbar.
• Low/No-Code-Umgebungen wie Power Pages.

Jeder kann einen besseren Ausgangspunkt für eine bestimmte Rolle bieten als etwas, das Sie von Grund auf neu eingerichtet haben, da sie vorhandene Schwerkraftzentren sind. Wenn Sie eine allgemeine Entwicklerplattform-API als Basisbasis verwenden, können Sie Dinge austauschen, experimentieren und im Laufe der Zeit ändern.

Erwägen Sie Web-Editor-Erweiterungen zum Erstellen eines Entwicklerportals

Wenn Sie nach einer webbasierten Erfahrung für Entwickler suchen, denken Sie daran, dass es sich bei einem aktuellen Trend um webbasierte Versionen von Editoren und IDEs handelt. Viele, wie solche, die VS Code verwenden, verfügen über Erweiterungsunterstützung. Mit VS Code wird alles, was Sie für diese Weberfahrungen erstellen, lokal für einen doppelten Vorteil übersetzt.

Neben Diensten wie GitHub Codespaces ist vscode.dev eine kostenlose Webversion des VS Code-Editors ohne Berechnung, umfasst jedoch Unterstützung für bestimmte Arten von Erweiterungen, einschließlich derjenigen, die Webviews für benutzerdefinierte Ui verwenden.

Auch wenn Ihre Entwickler VS Code selbst nicht verwenden, sind die UX-Muster bekannt und finden Sie in anderen Entwicklertools. Die Verwendung von vscode.dev kann neben dem Tool selbst eine bequeme und vertraute webbasierte Grundlage für Entwicklererfahrungen bieten.

Diese können als Entwicklerportal in vertrauter Form fungieren, das auch in die lokale Verwendung übersetzt werden kann.

ChatOps

Eine weitere Möglichkeit, die häufig übersehen wird, ist die Implementierung einer ChatOps-Schnittstelle. Angesichts der Zunahme chatbasierter Schnittstellen aufgrund des Anstiegs von KI-Produkten wie ChatGPT und GitHub Copilot können Aktionsbefehle oder Schrägstrichbefehle eine nützliche Möglichkeit zum Auslösen von Automatisierungsworkflows, zum Überprüfen des Status und mehr bieten. Da die meisten Anwendungs-CI-/CD-Plattformen out of box support for systems like Microsoft Teams, Slack, or Discord, this can be natural way to integration with another user interface developers and related operations roles use every day. Darüber hinaus verfügen alle diese Produkte über ein Erweiterbarkeitsmodell.

Investieren in ein neues Entwicklerportal

Angenommen, Sie verfügen nicht über ein Portal oder eine Vorhandene Schnittstelle, die Sie als Basis verwenden möchten, können Sie ein neues Entwicklerportal erstellen. Überlegen Sie sich dies als Ziel anstelle eines Ausgangspunkts. Wenn Sie noch nicht über ein Entwicklungsteam verfügen, das mit Ihnen arbeitet, ist dies die Zeit, dies zu tun. Jede Organisation ist anders, daher gibt es keine Antwort auf das, was in dieser Art von Erfahrung sein sollte. Daher gibt es keine Defacto-Antwort für ein vorgepacktes Produkt, das Sie so drehen und verwenden können, wie es heute ist.

Bei benutzerdefinierten integrierten selbst gehosteten Optionen sind allgemeine Webportalframeworks nicht neu, und Ihre Entwicklungsteams verwenden möglicherweise bereits einen, den Sie nutzen könnten. Wenn Sie versuchen, etwas vor Ihren Benutzern für ein frühes Feedback herauszuholen, könnten Sie sogar mit etwas so einfachem wie den Low-Code Power Pages beginnen, um eine Verbindung mit der allgemeinen Entwicklerplattform-API herzustellen.

Neuere Entwicklerportal-Bemühungen sind stärker meinungserwendigt. Beispielsweise ist Backstage.io ein benutzerdefiniertes Entwicklerportal-Toolkit, das zunächst entwickelt wurde, um die Anforderungen von Spotify zu erfüllen. Es enthält eine CLI, die Ihnen dabei hilft, Ihre Quellstruktur ähnlich wie create-react-app für React.js zu bootstrapieren.

Als Portal-Toolkit erfordert es Arbeit, um sich zu besorgen und Anpassungen erfordert Kenntnisse über TypeScript, Node.js und React. Das Große daran ist jedoch, dass Sie als Toolkit fast alles ändern können. Es verfügt auch über einen eigenen Softwarekatalog und vorlagenmechanismus, aber ihre Verwendung ist nicht erforderlich, und es hat eine gut definierte Methode, um neuen 1^st und 3^rd Party-Code namens Plug-Ins zu bringen.

Zugehöriger Inhalt

• Power Pages
• Backstage.io
• Anwenden von Software-Engineering-Systemen