Entwerfen einer Self-Service-Basis für Entwickler

Sobald Sie ihr Ziel für Ihre Technischen Systeme gut verstanden haben, können Sie mit der Erstellung anspruchsvollerer Entwickler-Self-Service-Umgebungen beginnen. In diesem Abschnitt wird eine konzeptionelle Architektur zum Erstellen oder Bewerten von Produkten beschrieben, die eine flexible Grundlage für deren Erstellung schaffen. Diese Konzepte, Muster und Komponenten werden gemeinsam als Self-Service-Basis für Entwickler bezeichnet.

Obwohl Sie möglicherweise nicht alles benötigen, was hier in Ihrem organization heute beschrieben wird, sollten Sie diese Konzepte im Auge behalten, wenn Sie etwas benutzerdefiniertes erstellen oder verwandte Produkte bewerten. In Ihrer Welt kann dieses Modell 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 Modells, die in diesem Abschnitt beschrieben werden, aber das Modell kann Sie dennoch bei der Orientierung unterstützen.

Goals und Überlegungen

Das wichtigste Ziel für Ihre Bemühungen in diesem Bereich sollte darin sein, Self-Service mit Leitplanken durch kontrollierte, gesteuerte Aufgabenausführung und -bereitstellung sowie zentralisierte Sichtbarkeit zu ermöglichen. Die Bereiche, auf die sie sich häufig am wertvollsten konzentrieren sollten, sind diejenigen, die entweder mühsam sind oder dinge sind, die der Entwickler aufgrund von Komplexität oder Berechtigungen nicht selbst erledigen kann. Dieser letzte Teil ist wichtig, damit Sie das Prinzip der geringsten Rechte befolgen können, ohne Entwickler durch einen manuellen Service Desk-Prozess zu zwingen.

Während Sie Ihre DevOps-Suite erweitern können, um diese Anforderungen zu erfüllen, müssen Sie wahrscheinlich mehrere Anwendungsplattformen im Laufe der Zeit unterstützen, und auch die spezifischen Tools und Prozesse, die sie unterstützen, müssen sich ändern. Das Hauptproblem besteht darin, dass Ihre Standards ein bewegendes Ziel sind. Wie ein Plattformtechniker sagte:

Die Schwierigkeiten sind die Standardisierung ... und umgang mit "abandonware"... Die Standardisierung wird häufig nicht erreicht, da automatisierte Prozesse möglicherweise unterbrochen werden können und die zeitaufwendige Aufgabe, notwendige Änderungen zu identifizieren. - Martin, DevOps Engineer, großes Logistikunternehmen

Wie dieses Angebot verdeutlicht, ist ein schneller Wechsel zu einem neuen oder aktualisierten Standard in der Regel nicht möglich, und das Aufgeben vorhandener Prozesse birgt Risiken. Ihr organization verwendet möglicherweise bereits mehrere DevOps-Suites oder unterschiedliche Kombinationen einzelner Tools und Entwicklerdienste nach Szenario. Selbst bei einem zentralen Team und einer Standardlösung ist variabilitätsfrei, wenn Ihre Self-Service-Anforderungen wachsen. Sie sollten also kontrollierte Experimente ermöglichen, bei denen bestimmte Teams neue Technologien, Bereitstellungsstrategien usw. ausprobieren können, gefolgt von einer bewussten Einführung und einem inkrementellen Rollout.

Im Allgemeinen fallen Self-Service-Erfahrungen in zwei primäre Kategorien:

• Automation
• Datenaggregation

Während die Datenaggregation eine gute Benutzererfahrung schafft, wie es ein Experte für Plattformtechnik ausdrückte:

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

Aus diesem Grund ist es wahrscheinlich, dass die von Ihnen gechartete Plattformentwicklung einige Probleme identifiziert hat, die durch Automatisierung gelöst werden könnten. Neben der Verringerung der kognitiven Last und des Aufwands für Entwickler kann die Automatisierung auch dazu beitragen, dass Anwendungen mit den besten Tools und Diensten für Den Betrieb, die 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 eine gewisse Datenaggregation nützlich, um automatisierte Anforderungen und die zugehörigen Ergebnisse nachzuverfolgen. Sie können häufig mit der Verknüpfung mit externen Systemen beginnen, um andere Anforderungen zu erfüllen oder Details zu drillen. Datenaggregation und -sichtbarkeit sind auch wichtig für die Überwachung, Governance und Reduzierung von Verschwendung (Beispiel: nicht verwendete Umgebungen).

Die Automatisierung von Dingen wie der Infrastrukturbereitstellung kann mithilfe von Systemintegrationen erfolgen, Sie können aber auch einen manuellen Workflowprozess auslösen und erleichtern, der für den Entwickler automatisiert aussieht. Dies ist nützlich in den frühen Phasen Ihrer Plattform, für neue Produkte, die Sie in Ihr Ökosystem einbringen, oder in Bereichen, in denen Sie ein System nicht automatisieren können oder haben (z. B. die Zuweisung von Softwarelizenzen). Mit dem richtigen Entwurf können Sie mit einem manuellen Prozess beginnen, der durch power automate erleichtert wird und im Laufe der Zeit zu einem vollständig automatisierten Ablauf umgestellt wird. Entwerfen Sie also von Anfang an eine Automatisierung.

Angesichts einer Produkt-Denkweise und der Idee einer dünnsten funktionsfähigen Plattform (TVP) (ein MVP für Ihre Plattform) sollten Sie einfach damit beginnen, vorhandene Investitionen wie Ihre Technischen Systeme oder ein internes Portal wiederzuverwenden, dann CLIs, grundlegende Webseiten oder sogar Power Pages-, Power BI- oder Microsoft Fabric-Dashboards zu erstellen und bei Bedarf zu erweitern. Vor diesem Hintergrund kann eine konsistente API, die UX dann verwendet, Ihnen helfen, mehrere Schnittstellen im Laufe der Zeit zu unterstützen, wenn sich Ihre Anforderungen und Einstellungen ändern.

Übersicht über Konzepte

Betrachten Sie die folgende Abbildung:

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

Komponente	BESCHREIBUNG
Entwicklerplattform-API	Dies ist Ihr single point of contact für User Experiences. Es ist effektiv der Vertrag des Systems mit anderen Systemen.
Graph der Entwicklerplattform	Ein verwaltetes und sicheres Datendiagramm, mit dem Sie verschiedene Arten von Entitäten und Vorlagen ermitteln, zuordnen und verwenden können. Eine Entität ist ein Objekt, das die Datenaggregation aus mehreren Quellen ermöglicht, während Vorlagen Benutzereingaben antreiben, die die Automatisierung ermöglichen.
Developer Platform Orchestrator	Eine Funktion, die vorlagenbasierte Anforderungen weiterleiten und nachverfolgt, um Aktionen entweder in einem System oder über einen manuellen Prozess auszuführen. Diese Anforderungen werden an einen der Entwicklerplattformanbieter weitergeleitet, die in eine beliebige Anzahl unterschiedlicher Workflowsysteme oder andere Dienste integriert werden können.
Entwicklerplattformanbieter	Eine Reihe von Komponenten, die Logik kapseln, die für die Integration in nachgeschaltete Systeme erforderlich ist, um CRUD-Vorgänge für Entitäten und/oder die Erfüllung vorlagenbasierter Aktionsanforderungen zu unterstützen. Jeder Anbieter kann seinen eigenen spezifischen Vorlagentyp unterstützen und entweder eindeutige oder allgemeine Entitätstypen ausgeben.
Benutzerprofil- und Teammetadaten	Eine Funktion zum Beibehalten von Informationen zu einer Gruppe von Personen, die an ein Konzeptteam für die Gruppierung und den Zugriff auf die Entwicklerplattform-API gebunden sind. Der Benutzer ist eng mit einem Identitätsanbieterkonto verknüpft (z. B. Microsoft Entra ID Anmeldung), aber sowohl er als auch ein Team können an eine beliebige Anzahl verwandter nachgeschalteter Systemdarstellungen gebunden werden. Eine Implementierung dieses Informationsspeichers besteht darin, das Entwicklerplattformdiagramm wiederzuverwenden. Die Self-Service-Foundation für Entwickler kann einen gemeinsamen Entitätstyp sowohl für einen Benutzer als auch für ein Team einrichten und diese Informationen im Diagramm beibehalten. Aus Gründen der Übersichtlichkeit werden wir diesen Speicher jedoch getrennt halten.

Diese grundlegenden Komponenten ermöglichen es Ihnen, verschiedene Bausteine im Laufe der Zeit zu verwenden und auszutauschen. In den folgenden Abschnitten werden diese ausführlicher erläutert.

Muss ich all dies erstellen, um zu beginnen?

Nein. Erstens ist dies ein konzeptionelles Modell, das Ihnen hilft, zu überlegen, was eine solche Stiftung tun sollte, sobald sie fertig ist. Zweitens sind die Implementierungsspezifischen hier weniger wichtig, da die Entwicklerplattform-API Ihre wichtigste Schnittstelle wird. Ihre erste Implementierung kann beginnen, Schnittstellen und Klassen in Ihrem Code für die verschiedenen Ebenen zu verwenden, die beschrieben oder in anderen Produkten kombiniert 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 Sie.

Vor diesem Hintergrund sollten wir uns mit jedem Stück näher beschäftigen.

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 zu ermöglichen oder die Bereitstellung und andere Aktionen zu steuern.

Diese API sollte auch als wichtige Authentifizierungs- und Sicherheitsebene fungieren, 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 die eigene Darstellung eines Benutzerprofils, die allgemeine 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

Angesichts der Breite einer internen Entwicklerplattform empfiehlt es sich, Systeme zu erstellen oder zu suchen, die einem erweiterbaren Anbietermodell folgen, um Funktionen in die API einzuführen. Die Idee besteht darin, dass wichtige Funktionen wie Automatisierung und Datenaggregation durch die Interaktion mit steckbaren Komponenten mit klar definierten Schnittstellen bereitgestellt werden. Diese lose Kopplung hilft Ihnen, inkrementell zu verdrahten, was Sie benötigen, und verbessert die Wartbarkeit, da Sie die Funktionalität unabhängig vom Rest des Fundaments testen können.

Es ist auch ein wichtiger Weg, um eine skalierbare innere Quellmentalität für Ihre Plattform zu ermöglichen. In der Regel können interne Beschaffungsbemühungen im Bereich Plattformentwicklung aufgrund von Herausforderungen bei der laufenden Wartung nicht an Fahrt gewinnen. Andere Teams sind möglicherweise bereit, Funktionen beizutragen, sind aber weniger bereit, etwas im Kern Ihrer Plattform zu warten und zu testen. Umgekehrt verfügt jedes zentralisierte Team über begrenzte Kapazitäten zum Verwalten von beigesteuertem Code oder sogar zum Überprüfen von Pull Requests. Das Konzept eines Entwicklerplattformanbieters entschärft diese Spannung, indem unabhängig geschriebener Code in die Kernfunktionen Ihrer Entwickler-Self-Service-Basis "integriert" werden kann. Obwohl Sie sorgfältig verwalten sollten, welche Anbieter Sie verwenden, jeden Anbietercode überprüfen und die Oberfläche begrenzen, auf die ein bestimmter Anbieter in Ihrer Entwicklerplattform zugreifen kann, kann ein pluggabler Ansatz Ihnen helfen, mehr zu erreichen, indem Sie den Aufwand auf einen breiteren Teil der organization 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 nachverfolgen, aktualisieren, präsentieren oder handeln muss. Entitäten können Beziehungen zueinander haben, die, wenn sie zusammengenommen, ein Diagramm bilden, das wichtige Informationen zu Teilen Ihrer internen Entwicklerplattform bereitstellt. Entwicklerplattformanbieter können dann Entitäten ausgeben, um Kernfunktionen zu aktivieren, z. B.:

• Ausnutzung extern bereitgestellter Ressourcen/Umgebungen oder verfügbarer APIs zur Ermittlung und Verwendung
• Verfügbarmachen von Beziehungen für Abhängigkeitsanalysen, Auswirkungsanalysen, Ermittlungen usw.
• Betreuer-/Besitzinformationen für Ermittlung und Zusammenarbeit
• Anzeigen von mehr Daten für die Verwendung in Benutzeroberflächen

Die Kapselung dieser Funktionalität in eine klar definierte Entwicklerplattformanbieterschnittstelle vereinfacht die Integration und Tests, ermöglicht eine unabhängige Bereitstellung und ermöglicht Entwicklern außerhalb des primären internen Entwicklerplattformteams die Mitwirkung und Verwaltung von Anbietern. Dies ist wichtig in großen oder divisionalen Organisationen, in denen nicht alle Tools, Dienste oder Plattformen zentral verwaltet werden, aber die breitere organization weiterhin Funktionen gemeinsam nutzen möchte. Selbst wenn Sie diesen Weg zunächst nicht gehen, ist es etwas, über das Sie langfristig nachdenken sollten.

Allgemeine Eigenschaften

Jede Entität sollte über einen Satz allgemeiner Eigenschaften verfügen, damit die Foundation sie verwalten kann. Zu den zu berücksichtigenden Eigenschaften gehören:

• Eindeutiger Bezeichner
• NAME
• Ursprungsanbieter
• Optionale Zuordnungen zu:
  • zuständige Benutzer
  • Eigenes Team
  • Andere Entitäten

Die Benutzer- und Teameigenschaften sind aus drei Gründen wichtig: Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), Ermittlung und Datenaggregation (z. B. Zusammenfassungen auf Teamebene). Das Erstellen von RBAC von Anfang an ist entscheidend für die Sicherheit und das Wachstum Ihrer internen Entwicklerplattform im Laufe der Zeit. Wenn Entwicklung ein Teamsport ist, wird die Entdeckung, mit wem man über eine Entität sprechen kann, schnell kritisch für Wiederverwendung, Unterstützung und Innersourcing.

Allgemeine und anbieterspezifische Entitäten

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

• Umgebungen
• Ressourcen
• APIs
• Repositorys
• Komponenten
• Tools

Diese sollten sich im Allgemeinen auf einer hohen Ebene befinden, wie Sie es im C4-Modellkontext oder in den meisten allgemeinen Komponentendiagrammen platzieren würden. Für eine Umgebung müssen Sie beispielsweise nicht die Details der internen Infrastrukturtopographie einschließen: Sie benötigen nur genügend Informationen, um verschiedene konzeptionelle Umgebungen von mehreren Anbietern in derselben Benutzeroberfläche aufzulisten und zuzuordnen. Die Entität kann auf niedrigere Detailebenen außerhalb des Systems verweisen, anstatt zu versuchen, alles zu nutzen. Diese bieten Ausgangspunkte für die Ermittlung, die für die Aktivierung der 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 unterscheidet sich in diesem Kontext von der Vorstellung von Entitäten darin, dass sie eine Aktion vorantreiben sollen. Beispielszenarien sind die Infrastrukturbereitstellung, das Erstellen eines Repositorys und andere prozesse mit langer Ausführungsdauer. Diese Vorlagen sollten auch über erweiterbare Entwicklerplattformanbieter verfügbar sein und dieselben allgemeinen 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 ist, die zum Ausführen der Aktion erforderlich sind. Diese können von der Benennung der Ressource bis hin zu optionalen Ergänzungen reichen.

Beispiele für Vorlagen sind:

• IaC-Vorlagen (Infrastructure-as-Code)
• Anwendungsvorlagen (Start Right) oder Vorlagenrepositorys
• Erstellen von Pipeline-/Workflowvorlagen
• Bereitstellungspipeline/Workflowvorlagen
• Parametrisierte Skripts
• Parametrisierte Power Automate-Flows (Beispiel: ein durch EINE HTTP-Anforderung ausgelöster Cloudflow)
• E-Mail-Vorlagen

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

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

Die tatsächlich zugrunde liegenden Vorlagendetails müssen nicht unbedingt zentral gespeichert werden. Sie können in verschiedenen Repositorys, Registrierungen oder Katalogen vorhanden sein. Beispielsweise können Sie GitHub-Vorlagenrepositorys für Ihre Anwendungsvorlagen verwenden, während Ihre IaC-Vorlagen in einem eingeschränkten Katalogrepository vorhanden sind, auf das Entwickler nur indirekt über Azure-Bereitstellungsumgebungen zugreifen können. Andere IaC-Vorlagen können in einer OCI-Artefaktregistrierung wie Helm-Diagrammen gespeichert werden. In anderen Fällen kann die Vorlage ein Verweis auf einen parametrisierten HTTP-Endpunkt sein. Ein Entwicklerplattformanbieter sollte gerade genug Informationen zu jedem Vorlagentyp bereitstellen, damit auf sie verwiesen werden kann, und zu allen Optionen, die für die Verwendung in benutzeroberflächen verfügbar gemacht werden können. Die Vorlagen selbst können jedoch am natürlichsten Ort für Ihre Anwendungsfälle untergebracht werden.

Plattformtechniker oder Experten für einen bestimmten Bereich schreiben diese Vorlage und teilen sie dann mit Entwicklungsteams zur Wiederverwendung. Die Zentralisierung der Verwendung dieser Vorlagen über ein System ermöglicht Entwickler-Self-Service und erstellt Leitplanken, die die Einhaltung von Organisationsstandards oder -richtlinien unterstützen. Mehr dazu, wenn wir den Entwicklerplattform-Orchestrator in ein wenig behandeln.

Graph der Entwicklerplattform

Sie können sich ein Graph der Entwicklerplattform als etwas vorstellen, mit dem Sie Entitäten und Vorlagen von 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 graphspezifischen Datenbank gespeichert werden. Stattdessen könnten Interaktionen mit Anbietern zusammen mit den erforderlichen Metadaten zwischengespeichert werden, damit alles zusammenpasst.

Das Diagramm ist leistungsfähig, wenn es mit gängigen Entitäten verwendet wird, die mehrere Anbieter beitragen können. Beispielsweise kann eine Liste von APIs von einem Produkt wie Azure API Center stammen, aber Sie können auch bereitstellungen und Umgebungen automatisch von Ihren Continuous Deployment-Systemen aus 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 die Zuordnung dennoch vornehmen können.

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 dasselbe Diagramm nutzen, sodass alle Aktionen, die von einem Entwicklerplattformanbieter ausgeführt werden, automatisch Entitäten beitragen, die für dieselbe API verfügbar sind.

Developer Platform Orchestrator

Ein Entwicklerplattform-Orchestrator ermöglicht Es Entwicklern oder Systemen, Anforderungen zum Ausführen einer Aktion mithilfe einer Vorlage zu erstellen. Es führt diese Aktionen nicht selbst aus, sondern koordiniert sich dafür mit einer Aufgaben-Engine, einer Workflow-Engine oder einem anderen Orchestrator. Es ist eines der wichtigen Elemente, die Sie sicher sein sollten, dass sie Teil Ihrer Self-Service-Grundlage ist. Es ermöglicht Entwicklern, Anforderungen mit einer Vorlage zu erstellen oder eine Aktion ohne direkte Berechtigung auszuführen. Darüber hinaus müssen sich diese Aktionen im Gegensatz zum Konzept von CI oder CD nicht auf den Anwendungsquellcode beziehen.

Wie unter Anwenden von Softwareentwicklungssystemen beschrieben, können Sie GitHub Actions, Azure Pipelines oder eine andere Workflow-Engine als Orchestrator verwenden. Dies ist ein vernünftiger Ausgangspunkt, aber Sie sollten ein wenig Abstraktion haben, um verschiedenen Vorlagentypen die Verwendung verschiedener zugrunde liegenden Engines zu ermöglichen. Dies kann aus mehreren Gründen nützlich sein:

• Zunächst sollten Sie wahrscheinlich in der Lage sein, im Laufe der Zeit unterschiedliche Workflow- und Aufgabenausführungs-Engines auswählen zu können, ohne einen Flashschnitt durchführen zu müssen. Wenn Sie mehrere Engines zulassen, können Sie im Laufe der Zeit oder einfach die Verwendung der neuen Engine zu neuen Aktionen migrieren, ohne dass sich dies auf ältere Aktionen auswirkt.
• Einige Prozesse, die Sie bei der Orchestrierung unterstützen möchten, erfordern möglicherweise zunächst manuelle Schritte, auch wenn Sie sie später vollständig automatisieren möchten.
• Andere Aktionen können auf Rollen außerhalb des Entwicklerteams abzielen, z. B. Die Kreditorenbuchhaltung 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 Hochsupieren eines so fähigen Vorgangs wie GitHub Actions oder Azure Pipelines nicht erforderlich oder kosteneffektiv für die Skalierung ist.

Glücklicherweise kann die Erweiterung der Idee eines Entwicklerplattformanbieters, um Die Schritte zur Trigger- und Nachverfolgungsautomatisierung abzudecken, diese erforderliche Abstraktion ermöglichen. Betrachten Sie die folgende Abbildung:

Hier ist das allgemeine Konzept:

1. Vorlagen können optional eine Reihe von Eingaben angeben, die der Benutzer eingeben kann. Wenn ein Entwickler eine bestimmte Aktion auslöst, wählt er eine Vorlage (auch wenn er nicht auf diese Weise beschrieben wird) und gibt eingaben ein.
2. Ein Verweis auf die vorlagenbezogenen Eingaben wird zu einer Anforderung in der Entwicklerplattform-API.
3. Sobald eine Anforderung übermittelt wurde, beginnt eine Anforderungsrouting- und -verarbeitungskomponente innerhalb des Orchestrators, den Lebenszyklus der Anforderung zu verfolgen. Die Vorlage für die Anforderungsrouting- und -verarbeitungskomponente leitet in der Anforderung an den Entwicklerplattformanbieter weiter, aus dem die Vorlage stammt.
4. Der Entwicklerplattformanbieter führt dann die entsprechenden Schritte für die Implementierung aus.
5. [Optional] Der Entwicklerplattformanbieter aktualisiert die Anforderung status, während er die Aktion ausführt.
6. Sobald die Anforderung erfüllt ist, kann der Entwicklerplattformanbieter eine Reihe von Entitäten zurückgeben, die im Graph der Entwicklerplattform hinzugefügt/aktualisiert werden sollen. Dies können anbieterspezifische oder allgemeine Entitäten sein.

Optional können Sie diesen Entwicklerplattformanbietern erlauben, die Entwicklerplattform-API direkt aufzurufen, um entweder mehr Entitäten als Eingaben abzurufen oder sogar eine andere zugehörige Aktion anzufordern.

Obwohl die spezifische Lösung oder ein Produkt, das Sie bewerten, variieren kann, sollte Ihnen dies ein Gefühl für die Qualitäten geben, nach den Sie suchen müssen.

In diesem Sinne sollten Sie einen Entwicklerplattformanbieter verwenden, der eine allgemeine Aufgabe oder Workflow-Engine verwendet. Genauer gesagt sollten Sie etwas überbrücken, was Sie im Rahmen von Apply Software Engineering Systems zusammengestellt haben. Eine allgemeine Workflow- oder Aufgabenausführungs-Engine, in die Sie wahrscheinlich investieren werden, ist Ihr CI/CD-System.

Beispiel für GitHub Actions oder Azure Pipelines

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

Für GitHub Actions besteht der Schlüssel dazu darin, dass ein Entwicklerplattformanbieter eine Verbindung mit dem angegebenen GitHub-instance 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 er der WORKFLOW-YAML-Datei eine workflow_dispatch Konfiguration hinzufügt. 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.

Diese Workflows/Pipelines müssen sich nicht in Quellcoderepositorys der Anwendung befinden. Das Konzept wäre, diese Tatsache zu nutzen, um etwas wie folgt zu tun:

1. Plattformtechniker 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.
2. Damit diese Workflows/Pipelines mit dem entsprechenden Downstreamsystem interagieren können, können Ops oder andere Mitglieder Ihres Plattformentwicklungsteams die erforderlichen Geheimnisse im zentralen Repository hinzufügen. Ausführliche Informationen hierzu finden Sie in GitHub Actions- und Azure DevOps-Dokumentation, oder Sie können die Geheimnisse mithilfe von Azure Key Vault zentralisieren.
3. Diese Workflows/Pipelines können dann einem Modell folgen, bei dem sie alle resultierenden Entitäten als Build-/Bereitstellungsartefakt veröffentlichen (GitHub-Dokumentation, Azure DevOps-Dokumentation).
4. Während einer Ausführung kann der Entwicklerplattformanbieter dann den Status des Workflows/der Pipeline watch und den Lebenszyklus status im Orchestrator aktualisieren, bis er abgeschlossen ist. Sie können beispielsweise Web-Hooks mit GitHub Actions und Diensthaken mit Azure Pipelines verwenden, um Updates nachzuverfolgen.
5. Nach Abschluss kann der Anbieter das veröffentlichte Artefakt bei Bedarf für die Aufnahme in das Graph der Entwicklerplattform nutzen.

Schließlich können Sie diesen Entwicklerplattformanbieter so einrichten, dass eine Gruppe von Vorlagen in das Entwicklerplattformdiagramm ausgegeben wird, die auf das entsprechende Repository und den entsprechenden Workflow bzw. die Pipeline verweisen, zusammen mit Eingaben für eine bestimmte Aufgabe.

Das Tolle an der Verwendung Ihres CI/CD-Systems ist, dass sie häufig so eingerichtet sind, dass die Ausführung beliebiger CLIs unterstützt wird, sodass Sie keine erstklassige, einzigartige Integration für alles benötigen, was Sie tun. Sie können diese nach Bedarf im Laufe der Zeit hinzufügen.

Vieles von dem, was in diesem Beispiel beschrieben wird, betrifft die Funktionsweise anderer Anbietertypen. Es ist auch wichtig zu beachten, dass die Verwendung von GitHub Actions oder Azure Pipelines in diesem Kontext nicht erfordert, dass Sie diese auch für Ihre tatsächlichen CI/CD-Pipelines verwenden.

Weitere Beispiele

Hier finden Sie einige Beispiele für andere Arten von Entwicklerplattformanbietern, die Vorlagen verarbeiten könnten.

Beispiel	BESCHREIBUNG
Quellcodeverwaltungsvorgänge	In einigen Fällen müssen Sie möglicherweise ein Repository erstellen oder aktualisieren, einen PR übermitteln oder einen anderen Vorgang im Zusammenhang mit der Quellcodeverwaltung ausführen. Während allgemeine asynchrone Workflow-Engines diese Arten von Vorgängen verwalten können, kann es nützlich sein, grundlegende Git-Vorgänge ohne diese auszuführen.
Infrastrukturbereitstellungen	Während GitHub Actions und Azure Pipelines gut für die Verwaltung der Infrastrukturbereitstellung funktionieren, können Sie sich auch für direktere Integrationen entscheiden. Ein dedizierter Anbieter kann die Einrichtung optimieren und Mehraufwand vermeiden. Dienste wie Azure-Bereitstellungsumgebungen oder Terraform Cloud sind direkter darauf ausgerichtet, die IaC-vorlagenbasierte Bereitstellung sicher und sicher zu ermöglichen. Andere Beispiele können z. B. das Erstellen von Kubernetes-Namespaces für Anwendungen in freigegebenen Clustern oder die Verwendung von Git mit GitOps-Workflows mit Flux oder Argo CD als bestimmten Anbietertyp umfassen. Noch apporientiertere Modelle wie das experimentelle Radius OSS-Inkubationsprojekt mit eigenen CLIs könnten im Laufe der Zeit eigene Entwicklerplattformanbieter haben. Das Wichtigste ist, nach der Erweiterbarkeit zu suchen und zu planen, damit Sie sich anpassen können.
Anwendungsgerüst/Seeding	Anwendungsvorlagen sind ein wichtiger Bestandteil von Plattformentwicklung im Laufe der Zeit. Sie können Ihre Vorlagen-Engine Ihrer Wahl unterstützen, indem Sie einen dedizierten Entwicklerplattformanbieter bereitstellen, der nicht nur zum Gerüstbau einer Anwendungsquellstruktur, sondern auch zum Erstellen und Pushen von Inhalten in ein Quellcoderepository konzipiert ist und die resultierenden Entitäten dem Diagramm hinzufügen soll. Jedes Ökosystem hat seine eigene Anwendungsgerüstpräferenz, egal ob Yeoman, Cookiecutter oder so etwas wie das Azure Developer CLI, sodass Sie mit dem Anbietermodell hier mehr als eine von Ihren gleichen Schnittstellen unterstützen können. Auch hier ist die Erweiterbarkeit entscheidend.
Manuelle Prozesse	Unabhängig davon, ob sie automatisch einen PR für die manuelle Genehmigung oder manuelle Workflowschritte für Nicht-Entwickler-Personen generieren, um auf eine Art wie Power Platform zu reagieren, kann dasselbe vorlagenbasierte Modell in einem Entwicklerplattformanbieter verwendet werden. Sie können im Laufe der Zeit sogar zu mehr automatisierten Schritten wechseln.

Obwohl Sie möglicherweise nicht alle diese Anbieter zum Starten benötigen, können Sie sehen, wie Erweiterbarkeit durch einen Entwicklerplattformanbieter Ihre Automatisierungsfunktionen im Laufe der Zeit wachsen lassen kann.

Benutzer und Teams

Plattformentwicklung ist von Natur aus eine Multisystem-Angelegenheit, daher ist es wichtig zu planen, wie eine Self-Service-Basis die schwierigeren Probleme bei der Integration dieser Systeme gemeinsam bewältigen sollte. In diesem Abschnitt behandeln wir eine Strategie zur Bewältigung allgemeiner Herausforderungen mit Identität, Benutzern und Teams.

Berücksichtigen Sie zunächst die folgenden beiden Empfehlungen:

Empfehlung	BESCHREIBUNG
Integrieren der Entwicklerplattform-API direkt in Ihren Identitätsanbieter für optimale Sicherheit	Um die Entwicklerplattform-API zu schützen, empfehlen wir die direkte Integration mit einem Identitätsanbieter wie Microsoft Entra ID angesichts der robusten Identität und der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) der Entra ID. Es gibt viele Vorteile, die nativen SDKs und APIs eines Identitätsanbieters (z. B. über MSAL Entra ID) anstelle einer Abstraktion zu verwenden. Sie können die End-to-End-Sicherheit steigern und sich auf dasselbe RBAC-Modell verlassen und gleichzeitig sicherstellen, dass Richtlinien für bedingten Zugriff kontinuierlich ausgewertet werden (und nicht nur zum Zeitpunkt der Anmeldung).
Verwenden von Integrationen von SSO- und Identitätsanbietergruppen in Nachgelagerten Systemen	Ihre Integrationen für einmaliges Anmelden (Single Sign-On, SSO) sollten denselben Identitätsanbieter und Mandanten verwenden, den Sie für Ihre Entwicklerplattform-API verwenden. Stellen Sie außerdem sicher, dass Sie die Unterstützung für Protokolle wie SCIM nutzen, um in Identitätsanbietergruppen (z. B. AD-Gruppen) zu verkabeln. Das Binden dieser Identitätsanbietergruppen in nachgeschaltete Systemberechtigungen erfolgt nicht immer automatisch, aber mindestens können Sie identifizierende Anbietergruppen den Gruppierungskonzepten jedes Tools manuell zuordnen, ohne die Mitgliedschaft anschließend manuell zu verwalten. Sie können beispielsweise die Unterstützung für verwaltete Benutzer (Enterprise Managed User , EMU) von GitHub kombinieren und manuell die Möglichkeit nutzen, Identitätsanbietergruppen mit GitHub-Teams zu verknüpfen. Azure DevOps verfügt über ähnliche Funktionen.

Als Nächstes werden wir aus diesen Empfehlungen ein Modell für die Behandlung schwierigerer Probleme in diesem Bereich erstellen.

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

Im Zuge Der Weiterentwicklung ihrer Plattformentwicklung werden Sie wahrscheinlich feststellen, dass Identitätsanbietergruppen sich hervorragend für die Verwaltung der Mitgliedschaft eignen, dass sich jedoch mehrere Gruppen zusammenfinden müssen, um das Konzept eines Teams für rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und Datenaggregation zu bilden.

Im Kontext der Plattformentwicklung definieren wir ein Team als eine Gruppe von Personen in verschiedenen Rollen, die zusammenarbeiten. Für die Datenaggregation ist die Idee eines Teams mit mehreren Rollen von entscheidender Bedeutung, um Die Ermittlung und das Rollup von Informationen an Orten wie Berichtsdashboards zu ermöglichen. Auf der anderen Seite ist eine Gruppe ein allgemeines Identitätsanbieterkonzept für eine Gruppe von Benutzern und wurde mit der Idee entworfen, mehrere Personen zu einer bestimmten Rolle hinzuzufügen, anstatt umgekehrt. Mit RBAC kann sich ein Team daher über unterschiedliche Rollen auf mehrere Identitätsanbietergruppen beziehen.

Die Quelle Ihrer Teamdaten kann von verschiedenen Orten stammen. Wenn Sie beispielsweise die Teams als Codemuster (TaC) verwenden, kann ein Entwicklerplattformanbieter für Dateiänderungen in einem Repository watch und sie in einem Benutzerprofil und Teammetadatenspeicher zwischenspeichern. Sie können auch direkt in ein Azure Dev Center-Projekt integrieren, in dem diese zentralen RBAC-Konstrukte bereits verfügbar sind.

Einrichten eines Modells für die Integration in nachgelagerte Systeme auf Team- oder Benutzerebene

Während einige Entwickler- und Betriebstools/-dienste Identitätsanbieterkonzepte direkt integrieren und verwenden, werden viele dies in ihre eigene Darstellung einer Gruppe oder eines Benutzers abstrahieren (auch mit einmaligem Anmelden). Diese Realität kann nicht nur den zugriff über tools hinweg, auch probleme für die Datenaggregation darstellen. Insbesondere können Sie feststellen, dass APIs im nachgelagerten System ihre eigenen Bezeichner anstelle von Identitätsanbieterbezeichnern verwenden (Beispiel: Die Objekt-ID in entra ID wird nicht direkt verwendet). Dies macht das Filtern und Zuordnen von Daten auf Benutzer- oder Teamebene schwierig, es sei denn, Sie können verschiedene IDs zuordnen.

Adressieren von Unterschieden auf Team- und Gruppenebene

Mit Mustern wie TaC können Sie Beziehungen zwischen den Team- oder Gruppenbezeichnern jedes Systems speichern und darauf zugreifen, sodass Sie sie zuordnen können. Um eine Zusammenfassung zu wiederholen, wird ein sicheres, überprüfbares Git-Repository zur Quelle eines Teams, und PRs bieten eine kontrollierte Benutzeroberfläche zum Durchführen von Updates. CI/CD-Systeme können dann nachgeschaltete Systeme aktualisieren und die zugehörigen Bezeichnerbeziehungen für das team beibehalten, das es dazu verwendet hat.

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

Wenn Sie lieber eine andere Datenquelle als Dateien in einem Repository ihrer Teams verwenden möchten, kann das gleiche allgemeine Konzept mithilfe des Developer Platform Orchestrator angewendet werden, um dasselbe zu erreichen. Bei diesem Modell kann ein Entwicklerplattformanbieter für die Quelle der Teamdaten ein Teamupdateereignis auslösen, das alle anderen Anbieter empfangen und entsprechend handeln.

Benutzer-ID-Herausforderungen behandeln

Eine weitere herausforderung für den Datenzugriff und die Aggregation sind Unterschiede bei der Benutzer-ID. Wenn Sie wie im Teamfall eine System-zu-System-Integration zum Abfragen von Daten zu einem Benutzer verwenden, können Sie nicht davon ausgehen, dass die native ID des Identitätsanbieters (z. B. Objekt-ID für Entra-ID) eine bestimmte API unterstützt. Auch hier kann das Speichern einer Zuordnung für eine Benutzer-ID helfen, die über die Entwicklerplattform-API auf Daten zugreift. Beispiel: GitHub:

Wenn Sie für jedes System eine Benutzer-ID eines anderen Systems über eine API ohne Benutzertoken suchen 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 einem Massenvorgang ausführen und die Ergebnisse als Referenz zwischenspeichern müssen, um die Leistung zu erhalten.

Zurückgreifen auf die Verwendung mehrerer Benutzertoken

In Situationen, in denen Anbieter auf Daten auf Benutzerebene zugreifen müssen, ohne eine Möglichkeit zur Übersetzung der Benutzer-ID durchzuführen, die funktionieren würde, kann die Entwicklerplattform-API eingerichtet werden, um mehrere Benutzertoken zu verwalten. Beispiele:

1. Die Entwicklerplattform-API könnte einen Cache von anbieterspezifischen Benutzertoken für die Verwendung mit nachgeschalteten Systemen unterstützen.
2. Alle Interaktionen mit einem bestimmten Anbieter, die von der API ausgelöst werden, werden im Benutzertoken des Anbieters enthalten, sofern verfügbar.
3. Um den Fall zu behandeln, in dem kein Benutzertoken verfügbar war, löst der Anbieter einen OAuth-Flow aus, um eins zu erhalten.
4. Zu Beginn übergibt die Entwicklerplattform-API einen Authentifizierungs-URI für einen OAuth-Flow mit einem Umleitungs-URI, der an den Anbieter übergeben wurde. Der übergebene URI würde einen Nonce-/Einmalverwendungscode enthalten.
5. Die API gibt dann eine "nicht authentifizierte" Antwort mit dem URI zurück.
6. Jede UX kann diesen URI dann verwenden, um den entsprechenden Authentifizierungsflow in einem Browser zu steuern.
7. Sobald die Umleitung erfolgt ist, erhält die Entwicklerplattform das erforderliche Benutzertoken und speichert es für die zukünftige Referenz zusammen mit der Benutzer-ID zwischen.
8. Der Client könnte dann den API-Aufruf wiederholen, was dann erfolgreich war.

Dieses Konzept beschreibt eine Möglichkeit, mit komplizierten Authentifizierungen umzugehen, da Sie IDs nach Möglichkeit wiederverwenden können und keine separaten Umleitungs-URIs pro nachgeschaltetem System verwalten müssen.

Aggregieren von Daten und Bereitstellen zusätzlicher Funktionen

Verwenden kontextbezogener DeepLinks zu Tools und Berichtssystemen

Bis zu diesem Punkt haben wir über den Automatisierungsaspekt des Problemraums gesprochen. Dies allein kann einen großen Weg 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.

Auch wenn keine Automatisierung im Zusammenhang steht, können Entwicklerplattformanbieter jede Art von Entitätsbedarf ausgeben. Sie möchten jedoch in der Regel nicht alle detaillierten Daten ihrer gesamten internen Entwicklerplattform in Ihr Entwicklerplattformdiagramm einbinden. Dashboards in Beobachtbarkeitslösungen wie Grafana, Prometheus, DataDog oder Code Intelligence in Produkten wie SonarQube und native Funktionen in DevOps-Suiten wie GitHub und Azure DevOps sind alle sehr leistungsfähig. Stattdessen besteht der beste Ansatz häufig darin, Deep Links in diese anderen Systeme 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 toolsübergreifend aggregierte und zusammengefasste Daten benötigen oder benutzerdefinierte Metriken steuern müssen, können Berichterstellungslösungen Power BI oder Microsoft Fabric ihr nächster Anrufhafen sein. Zum Zusammenführen von Teamdaten können Sie entweder eine Verbindung mit der Datenbank Ihrer Foundation herstellen oder eine Entwicklerplattform-API verwenden. Wie unter Planen und Priorisieren beschrieben, können Sie beispielsweise eine benutzerdefinierte Dashboard den Erfolg Ihrer internen Entwicklerplattform messen.

Seien Sie bei jeder zusätzlichen Benutzeroberfläche, die Sie erstellen, selektiv

Es kann zwar attraktiv sein, vorhandene Funktionen in einem gängigen Portal neu zu erstellen, denken Sie jedoch daran, dass Sie diese auch verwalten müssen. Dies ist der Bereich, in dem es wichtig ist, einer Produktmentalität zu folgen. Schnittstellen im Dashboardstil sind leicht zu verstehen und zu verstehen, aber Ihre Entwickler finden möglicherweise an anderer Stelle mehr Wert.

Allerdings können Sie mit dem Modell hier aggregierte Daten im Graph der Entwicklerplattform verwenden, um benutzerdefinierte Benutzeroberflächen zu erstellen. Entitäten sollten über eine integrierte Unterstützung verfügen, damit sie an einen Benutzer oder ein Team gebunden werden können. Dadurch kann Ihre Entwicklerplattform-API den Bereich der Ausgabe (zusammen mit der Indizierung und Zwischenspeicherung) festlegen.

Selbst wenn Sie jedoch eine benutzerdefinierte UX anstelle eines DeepLinks erstellen müssen, ist das Pullen aller Daten in Ihr Entwicklerplattformdiagramm in der Regel immer noch nicht der beste Ansatz. Betrachten Sie beispielsweise eine Situation, in der Sie Protokolle in Ihrer Benutzeroberfläche anzeigen möchten, die bereits über eine klar definierte und verwaltete Startseite verfügen. Verwenden Sie Informationen in den zugehörigen Entitäten, um Ihre UX dabei zu unterstützen, Informationen direkt aus nachgeschalteten Systemen zu sammeln.

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

Hier sind einige Beispiele für allgemeine Erfahrungen, die berücksichtigt werden sollten:

Beispiel	BESCHREIBUNG
Entdeckung und Erkundung	Wie ein Plattformentwickler es ausdrückte: "Was Projekte verlangsamt, ist Kommunikation, nicht Entwicklerfähigkeiten." – Daniel, Cloud Engineer, Fortune 500 Media Company. Da Software ein Teamsport ist, ist das Erstellen einer Benutzeroberfläche zur Ermittlung von Teams und den Entitäten, die sie besitzen, in der Regel eines der ersten Schritte, die sie angehen müssen. Teamübergreifende Suche, Ermittlung und Dokumentation tragen dazu bei, die Wiederverwendung zu fördern und die Zusammenarbeit für die interne Beschaffung oder den Support zu unterstützen. Teams profitieren auch von einer zentralen Anlaufstelle, um eigene Dinge zu finden, z. B. Umgebungen, Repositorys und andere Ressourcen wie Dokumentationen.
Manuelle Registrierung von Umgebungen oder Ressourcen	Während viele Dinge über den Entwicklerplattform-Orchestrator bereitgestellt und nachverfolgt werden können, können Sie auch Ressourcen oder Umgebungen registrieren, die bereits vorhanden sind oder noch nicht automatisiert sind. Ein einfacher Anbieter, der Informationen aus einem Git-Repository übernimmt und Informationen zur Ressourcen-/Umgebungsverwaltung hinzufügt, kann hier nützlich sein. Wenn Sie bereits über einen Softwarekatalog verfügen, wird dies auch eine Möglichkeit, ihn in das Modell zu integrieren.
Ein API-Katalog	Die Nachverfolgung von APIs, die Entwickler verwenden sollten, kann einen großen Weg gehen. Wenn Sie noch nicht über etwas verfügen, können Sie sogar mit einem einfachen Git-Repository mit einer Reihe von Dateien beginnen, die APIs, deren status darstellen, PRs verwenden, um Ihren Genehmigungsworkflow zu verwalten. Diese können Ihrem Entwicklerplattformdiagramm hinzugefügt werden, sodass sie angezeigt oder anderen Entitäten zugeordnet werden können. Für robustere Funktionen können Sie beispielsweise das API Center von Microsoft oder ein anderes Produkt integrieren.
Lizenzkonformität	In einigen Fällen können Sie auch Einblick in die Softwarelizenzkonformität und die Platznutzung bieten. Entwicklerplattformen können auch die Automatisierung hinzufügen, die zum Verbrauch von Arbeitsplätzen erforderlich ist, aber selbst wenn Arbeitsplätze manuell zugewiesen werden (z. B. über einen PR-Prozess in einem Git-Repository), können Entwickler einblicken, was sie haben (und die Möglichkeit des Administrators, alles zu sehen).
Eine anwendungsorientierte Ansicht von Kubernetes	Wenn Sie einen freigegebenen Kubernetes-Cluster verwenden, kann es für Entwickler schwierig sein, den Status ihrer Anwendungen über die Clusteradministrator-UX zu finden und zu verstehen. Verschiedene Organisationen haben sich dafür entschieden, dieses Problem unterschiedlich zu behandeln, aber die Verwendung eines Namespace zur Darstellung einer Anwendung ist eine bekannte Möglichkeit, dies zu tun. Von dort aus können Sie Entitäten verwenden, um Zuordnungen zwischen dem Namespace der Anwendung im Cluster und einem Team herzustellen und eine stärker entwicklerorientierte Ansicht der status für die Anwendung zu erstellen und DeepLinks zu anderen Tools oder Web-UIs bereitzustellen.

Benutzeroberfläche

Verschiedene Rollen in Ihrem organization verfügen über Tools oder Dienste, die einen Schwerpunkt für ihre tägliche Arbeit darstellen. Der Sog dieser Systeme kann es für neue Benutzererfahrungen außerhalb dieser Schwerpunkte schwierig machen, an Traktion zu gewinnen. In einer perfekten Welt können Entwickler, Betriebsabläufe und andere Rollen weiterhin in einer Umgebung arbeiten, die für sie sinnvoll ist – oft die, die sie bereits verwenden.

Vor diesem Hintergrund ist die Planung mehrerer Benutzeroberflächen während Der Entwicklung Ihrer Plattformentwicklung eine gute Idee. Dies kann auch eine Möglichkeit bieten, einfach zu beginnen, sich zu beweisen und bei Bedarf zu komplexeren Schnittstellen zu wachsen.

Integrieren Ihrer Möglichkeiten

Wenn Sie sich die Artikel Anwenden von Softwareentwicklungssystemen und Verfeinern der Anwendungsplattform durchgelesen 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 beginnen. (Fragen Sie sich selbst, werden die Benutzer besser auf eine andere neue Benutzeroberfläche oder eine verbesserte Version von etwas reagieren, das sie jetzt haben?)

Einige der Tools, Hilfsprogramme 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 erhalten einen großen Nutzen, wenn 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.

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

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

Jede kann einen besseren Ausgangspunkt für eine bestimmte Rolle bieten als etwas, das Sie von Grund auf neu eingerichtet haben, da es sich um vorhandene Schwerpunkte handelt. Wenn Sie eine gemeinsame Entwicklerplattform-API als Basis verwenden, können Sie Dinge austauschen, experimentieren und sich im Laufe der Zeit ändern.

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

Wenn Sie nach einer webbasierten Benutzeroberfläche für Entwickler suchen, denken Sie daran, dass ein aktueller Trend webbasierte Versionen von Editoren und IDEs sind. Viele, wie diejenigen, die VS Code verwenden, verfügen über Erweiterungsunterstützung. Mit VS Code wird alles, was Sie für diese Webumgebungen erstellen, lokal übersetzt, um einen doppelten Vorteil zu erzielen.

Neben Diensten wie GitHub Codespaces ist vscode.dev eine kostenlose Webversion des VS Code-Editors ohne Compute, bietet aber Unterstützung für bestimmte Arten von Erweiterungen , einschließlich solcher, die Webviews für benutzerdefinierte UI verwenden.

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

Diese können als entwicklerorientiertes Portal in einer vertrauten Form fungieren, die 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 von Chat-basierten Schnittstellen aufgrund der Zunahme von KI-Produkten wie ChatGPT und GitHub Copilot können Aktionsbefehle oder Schrägstrichbefehle eine nützliche Möglichkeit bieten, Automatisierungsworkflows auszulösen, status zu überprüfen und vieles mehr. Da die meisten CI/CD-Anwendungsplattformen über eine sofort einsatzbereite Unterstützung für Systeme wie Microsoft Teams, Slack oder Discord verfügen, kann dies eine natürliche Möglichkeit zur Integration in andere Benutzeroberflächenentwickler und zugehörige Betriebsrollen sein, die täglich verwendet werden. 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 Schnittstelle, die Sie als Basis verwenden möchten, können Sie sich entscheiden, ein neues Entwicklerportal zu erstellen. Stellen Sie sich dies als Ziel und nicht als Ausgangspunkt vor. Wenn Sie noch nicht über ein Entwicklungsteam verfügen, das mit Ihnen arbeitet, ist es an der Zeit, diese Bemühungen zu starten. Jede organization ist anders, sodass es keine universelle Antwort auf das gibt, was in dieser Art von Erfahrung sein sollte. Daher gibt es keine defacto-Antwort für ein vorverpacktes Produkt, das Sie wie bisher für so etwas verwenden können.

Für benutzerdefinierte, selbstgehostete Optionen sind allgemeine Webportalframeworks nicht neu, und Ihre Entwicklungsteams verwenden möglicherweise bereits ein Framework, das Sie nutzen können. Wenn Sie versuchen, ihren Benutzern ein frühes Feedback zu geben, können Sie sogar mit etwas so einfachem wie der Low-Code-Power Pages beginnen, um eine Verbindung mit der api für allgemeine Entwicklerplattform herzustellen.

Neuere Entwicklerportal-Bemühungen sind eher Meinungen. Beispielsweise ist Backstage.io ein benutzerdefiniertes Entwicklerportal-Toolkit, das ursprünglich für die Anforderungen von Spotify entwickelt wurde. Es enthält eine CLI, die Sie beim Bootstrap Ihrer Quellstruktur unterstützt, ähnlich wie create-react-app für React.js.

Als Portaltoolkit erfordert es Arbeit, um aufstehen zu können, und die Anpassung erfordert Kenntnisse in TypeScript, Node.js und React. Das Tolle 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 Möglichkeit, neuen 1^st- und 3 rd-Party-Code namens Plug-Ins zu bringen.