Self-Service-Plattformarchitektur für Entwickelnde
Eine Self-Service-Umgebung für Entwickelnde basiert auf einer Kombination von Konzepten, Mustern und Tools, die benutzerdefinierte Technologien sowie Off-The-Shelf- und Open-Source-Technologien umfassen. Ziel ist es, Entwickelnde die Ausführung und Bereitstellung gesteuerter Aufgaben zu ermöglichen und gleichzeitig eine zentralisierte Sichtbarkeit beizubehalten. Der Primäre Fokus sollte auf Aufgaben liegen, die mühsam oder zu komplex sind, um durch Entwickelnde unabhängig voneinander ausgeführt zu werden.
Self-Service-Plattformkomponenten für Entwickelnde
Eine Self-Service-Umgebung für Entwickelnde besteht aus mehreren wichtigen Komponenten, die zusammenarbeiten, um Workflows für Entwickelnde zu optimieren und zu automatisieren. Zu diesen Komponenten gehören die Entwicklerplattform-API, der Entwicklerplattformgraph, der Entwicklerplattformorchestrator, die Entwicklerplattformanbieterund die Metadaten zu Benutzerprofilen und Teams.
Die Entwicklerplattform-API fungiert als zentraler Interaktionspunkt, der als vertragliche Schnittstelle zwischen Benutzeroberflächen und weiteren Systemen dient. Eine Entwicklerplattform-API sollte den Datenzugriff ermöglichen und Bereitstellungsaktionen über verschiedene Benutzeroberflächen steuern. Sie dient als primäre Authentifizierungs- und Sicherheitsschicht und schränkt den Zugriff auf zugrunde liegende, unformatierte APIs zusammen mit den entsprechenden Daten und Vorgängen ein. Die API verwaltet Benutzerprofile, Rollen innerhalb der Plattform und primäre Identitätsanbieter-IDs, um eine ordnungsgemäße Zugriffssteuerung sicherzustellen.
Die Entwicklerplattform-API wird durch den Entwicklerplattformgraphen ergänzt. Dieser stellt eine sichere, verwaltete Datenstruktur dar, die die Ermittlung und Zuordnung von Entitäten und Vorlagen innerhalb der Plattform erleichtert. Entitäten aggregieren Daten aus mehreren Quellen, während Vorlagen die Eingaben von Benutzenden für die Automatisierung leiten.
Mithilfe des Entwicklerplattformgraphs können Sie einer durchsuchbaren Struktur Entitäten und Vorlagen mehrerer Anbietern zuordnen. Während die Daten für diese Entitäten nicht direkt in einer Graphdatenbank gespeichert werden müssen, können Interaktionen mit Anbietern zusammen mit den erforderlichen Metadaten zwischengespeichert werden. Dieser Graph ist insbesondere bei der Arbeit mit allgemeinen Entitäten wertvoll, die von mehreren Anbietern stammen. Beispielsweise können APIs aus Azure API Center stammen, während Bereitstellungen und Umgebungen aus Continuous-Deployment-Systemen abgerufen werden. Der Graph unterstützt Umgebungen für Benutzende über eine allgemeine API, die Ermittlung, Suche und Governance ermöglicht.
Zum Ausführen vorlagenbasierter Aktionen leitet der Entwicklerplattformorchestrator Anforderungen weiter und verfolgt diese nach. Dabei stimmt er sich mit spezialisierten Entwicklerplattformanbietern ab, die mit Downstreamsystemen integriert werden. Der Orchestrator ermöglicht es Entwickelnden oder Systemen, Aktionen mithilfe von Vorlagen anzufordern, ohne die Aktionen direkt auszuführen. Er stimmt sich mit einer Aufgaben-Engine, einer Workflow-Engine oder einem weiteren Orchestrator ab, um die Aktionen auszuführen. Diese Komponente ist für den Self-Service unerlässlich, da sie es Entwickelnden ermöglicht, Aktionen auszulösen, ohne direkte Berechtigungen zu benötigen. Im Gegensatz zu CI/CD sind diese Aktionen nicht auf den Anwendungsquellcode beschränkt. Workflowmodule wie GitHub Actions oder Azure Pipelines können als Orchestratoren dienen, eine Abstraktion kann jedoch hilfreich sein, um im Laufe der Zeit verschiedene Engines zu unterstützen. Diese Flexibilität ermöglicht die Engine-Migration, unterstützt manuelle Schritte für Prozesse, die später automatisiert werden können, und bietet Aktionen für Nichtentwicklungsrollen wie Kreditorenkonten. Darüber hinaus können einfachere Aufgaben über HTTP-Anforderungen verarbeitet werden, wodurch komplexe Engines nicht erforderlich sind.
Entwicklerplattformanbieter verwalten die Logik für CRUD-Vorgänge (Create, Read, Update, and Delete – Erstellen, Lesen, Aktualisieren und Löschen) für Entitäten und die Ausführung von Aktionsanforderungen. Zudem unterstützen sie verschiedene Workflows und Dienste. Die Anbieter führen Funktionalität über ein erweiterbares Anbietermodell in die API ein und ermöglichen wichtige Features wie Automatisierung und Datenaggregation. Dieses Modell fördert eine lose Kopplung, ermöglicht eine inkrementelle Integration neuer Funktionalität und verbessert die Wartbarkeit. Durch die Förderung einer Inner-Source-Mentalität kann Plattformfunktionalität durch verschiedene Teams beigetragen und verwaltet werden, wodurch der Wartungsaufwand für zentrale Teams minimiert wird. Obwohl es wichtig ist, Anbietercode zu prüfen und den Zugriff sorgfältig zu verwalten, trägt dieser austauschbare Ansatz dazu bei, den Entwicklungsaufwand in der gesamten Organisation zu skalieren.
Die Umgebung umfasst außerdem Funktionen zum Verwalten der Metadaten von Benutzerprofilen und Teams, wodurch Informationen von Einzelpersonen oder Teams mit Konten verknüpft werden, die von einem Identitätsanbieter wie Microsoft Entra ID gehostet werden. Diese Metadaten werden für die Gruppierung und Zugriffssteuerung innerhalb der Entwicklerplattform-API verwendet. Obwohl es möglich wäre, diese Informationen im Entwicklerplattformgraphen zu speichern, sorgt die Trennung für Klarheit.
Auf eine Self-Service-Umgebung für Entwickelnde kann über eine zentralisierte Benutzeroberfläche (UI bzw. UX) zugegriffen werden. Durch das Anbieten eines einheitlichen Zugriffspunkts werden Interaktionen für Entwickelnde optimiert, wodurch die Verwendung von Workflows und Ressourcen nahtlos und intuitiv erleichtert wird.
Eine Self-Service-Umgebung für Entwickelnde muss nicht von Anfang an vollständig erstellt werden. Sie dient vielmehr als konzeptioneller Orientierungspunkt für Funktionen im Laufe der Zeit. Erste Implementierungen können durch die Verwendung vorhandener Tools, Schnittstellen oder Klassen vereinfacht werden, um die dringendsten Prioritäten zu bearbeiten, die durch Kundenfeedback identifiziert wurden. Durch kleine Schritte kann sich die Umgebung so entwickeln, dass neuen Anforderungen effektiv gerecht wird.
Schlüsselkonzepte für Entwicklerplattformanbieter
Bei einer Entwicklerplattform basiert die effektive Verwaltung und Orchestrierung von Ressourcen auf der Verwendung von Entitäten zusammen mit ihren Eigenschaften und Vorlagen. Diese Schlüsselkonzepte bieten Struktur und Automatisierung, ermöglichen die nahtlose Integration verschiedener Anbieter und erleichtern konsistente Workflows und Governance.
Entitäten
Entitäten sind die wichtigsten Objekte, die Entwickelnde oder ein System innerhalb der internen Entwicklerplattform nachverfolgen, aktualisieren, präsentieren oder bearbeiten müssen. Diese Entitäten können Beziehungen zueinander aufweisen, und sie erstellen einen Graphen, der wichtige Informationen über die Plattform bereitstellt. Entwicklerplattformanbieter können Entitäten ausgeben, um verschiedene Kernfunktionen wie das Ermitteln externer Ressourcen, das Ausführen einer Abhängigkeitsanalyse oder das Erkennen von Besitz- und Wartungsinformationen zu unterstützen. Eine gut definierte Anbieterschnittstelle vereinfacht Integration, Tests und Bereitstellung und ermöglicht es Entwicklungsteams, unabhängig voneinander zu arbeiten.
Allgemeine Eigenschaften
Um Entitäten effektiv zu verwalten, ist es hilfreich, eine Reihe allgemeiner Eigenschaften zu definieren. Einige vorgeschlagene Eigenschaften umfassen einen eindeutigen Bezeichner, einen Namen, einen ursprünglichen Anbieter und optionale Zuordnungen zu Benutzenden, Teams oder weiteren Entitäten. Diese Eigenschaften sind für die rollenbasierte Zugriffssteuerung (RBAC), die Ermittlung und die Datenaggregation wichtig. Die RBAC-Implementierung zu Beginn ist für die Sicherheit und Skalierung der Plattform im Laufe der Zeit von entscheidender Bedeutung. Die Zuordnungen von Benutzenden und Teams sind besonders wertvoll, da sie die Ermittlung und Zusammenarbeit unterstützen und eine effiziente Wiederverwendung, Unterstützung und Inner Sourcing innerhalb der Plattform ermöglichen.
Allgemeine und anbieterspezifische Entitäten
Sie sollten ebenfalls eine Reihe häufiger, allgemeiner, normalisierter Entitäten definieren, die von mehreren Anbietern ausgegeben werden können. Diese können Umgebungen, Ressourcen, APIs, Repositorys, Komponenten und Tools einschließen. Diese Entitäten sollten konzeptionell sein und sich auf die allgemeine Kategorisierung wie Umgebungen und nicht auf präzise technische Details wie die interne Infrastruktur konzentrieren. Diese allgemeine Ansicht erleichtert die Ermittlung und ermöglicht die Datenaggregation im Laufe der Zeit, während sie auf spezifische Details außerhalb des Systems verweist. Darüber hinaus müssen Sie bei der Entwicklung Ihrer Plattform möglicherweise eine wachsende Gruppe anbieterspezifischer Entitätstypen berücksichtigen, um verschiedene Anwendungsfälle abzudecken.
Vorlagen
Vorlagen dienen dazu, Aktionen wie Infrastrukturbereitstellung, Repositoryerstellung oder weitere Prozesse mit langer Ausführungsdauer voranzutreiben. Diese Vorlagen sind über Entwicklerplattformanbieter verfügbar und enthalten allgemeine Eigenschaften wie Entitätszuordnungen und erforderliche Eingaben wie Ressourcennamen. Vorlagen können verschiedene Formate darstellen: Infrastructure-as-Code-Vorlagen (IaC), Anwendungsvorlagen oder parametrisierte Skripts. Sie sind häufig anbieterspezifisch und verfügen je nach verwendeter Technologie über unterschiedliche Darstellungen auf. Beispiele für diese Darstellungen sind Terraform- oder Bicep-Vorlagen, Helm-Diagramme, parametrisierte GitHub Actions-Workflows, Azure Pipelines, einfache Skripts oder benutzerdefinierte Formate, die auf bestimmte Anbieterökosysteme zugeschnitten sind.
Obwohl Vorlagen nicht zentral gespeichert werden müssen, ist für einen konsistenten Zugriff auf die gesamte Plattform der Zugriff auf diese Vorlagen über einen Anbieter erforderlich. Sie können je nach Anwendungsfall in verschiedenen Repositorys, Registern oder Katalogen vorhanden sein. Beispielsweise können GitHub-Vorlagenrepositorys für Anwendungsvorlagen verwendet werden, während sich IaC-Vorlagen in einem eingeschränkten Katalogrepository befinden können, auf das Entwickelnde über Tools wie Azure Deployment Environments indirekten Zugriff haben. Weitere IaC-Vorlagen wie Helm-Diagramme können in einer Open Container Initiative-Artefaktregistrierung (OCI) gespeichert werden. In einigen Fällen verweist eine Vorlage möglicherweise lediglich auf einen parametrisierten HTTP-Endpunkt.
Technische Fachkräfte für Plattformen oder Fachkräfte für Domänen erstellen in der Regel diese Vorlagen und geben sie für Entwicklungsteams zur Wiederverwendung frei. Durch die zentralisierte Verwendung von Vorlagen in einem System wird der Zugriff erleichtert, während organisatorische Standards und Richtlinien durchgesetzt werden. Dieser Prozess trägt dazu bei, die Kontrolle und Compliance auf der gesamten Plattform aufrechtzuerhalten und Entwickelnden eine effizienter Arbeit zu ermöglichen.
GitHub Actions als Plattformanbieter
Die Funktionsweise von Anbietern wird anhand von GitHub Actions und Azure Pipelines veranschaulicht. Beide können als Entwicklerplattformanbieter fungieren, indem Workflows ausgelöst oder Pipelines über ihre jeweiligen APIs wie die REST-API für GitHub Actions oder die Pipeline-API für Azure DevOps ausgeführt werden. Diese Workflows oder Pipelines müssen nicht in Quellcoderepositorys von Anwendungen gespeichert werden, wodurch technische Fachkräfte für Plattformen sie in zentralen, privaten Repositorys verwalten können. In diesem Modell haben Entwickelnde keinen direkten Zugriff auf die Workflows, können jedoch einen Entwicklerplattformanbieter verwenden, um mit ihnen zu interagieren. Der Anbieter kann erforderliche Geheimnisse wie Anmeldeinformationen oder API-Schlüssel durch die Integration mit Diensten wie Azure Key Vault verwalten. Bei der Ausführung von Workflows verfolgt der Anbieter ihren Status mithilfe von Webhooks für GitHub Actions und Diensthooks für Azure Pipelines nach, um den Fortschritt zu überwachen. Sobald der Workflow abgeschlossen ist, werden alle erstellten Artefakte wie Build- oder Bereitstellungsergebnisse erfasst und veröffentlicht. Diese Artefakte können dem Entwicklerplattformgraphen zusammen mit Eingabeparametern und Verweisen auf die Workflows hinzugefügt werden. Dieser Ansatz ermöglicht außerdem Flexibilität bei der Verwendung beliebiger CLIs und unterstützt eine Vielzahl von Automatisierungsaufgaben im Laufe der Zeit. Darüber hinaus ist die Verwendung von GitHub Actions oder Azure Pipelines in diesem Kontext unabhängig von ihrer traditionellen CI/CD-Rolle und bietet eine umfassendere Anwendbarkeit für die Verwaltung verschiedener Prozesse und Vorlagen.
Es gibt weitere Arten von Entwicklerplattformanbietern, die über Vorlagen verschiedene Aufgaben verarbeiten können. Für Quellcodeverwaltungsvorgängen können Anbieter Git-Aufgaben wie das Erstellen von Repositorys, das Übermitteln von Pull Requests (PRs) oder weitere Git-Vorgänge unterstützen, ohne sich auf allgemeine Workflow-Engines zu verlassen. Die Infrastrukturbereitstellung kann durch dedizierte Anbieter wie Azure Deployment Environments oder Terraform Cloud optimiert werden. Dabei liegt der Schwerpunkt auf Infrastruktur als Code (IaC) mit Sicherheit und Effizienz. Anwendungsgerüstanbieter wie Azure Developer CLI unterstützen das Erstellen von Anwendungsquellstrukturen und pushen diese an Quellrepositorys, wodurch für verschiedene Ökosysteme Flexibilität entsteht. Manuelle Prozesse wie das Generieren von Pull Requests (PRs) oder das Automatisieren von Workflows für Nichtentwickelnde können außerdem über vorlagenbasierte Anbieter verwaltet werden, wodurch eine schrittweise Automatisierung ermöglicht wird. In diesen Beispielen wird hervorgehoben, wie Automatisierungsfunktionen durch die Erweiterbarkeit und Anpassungsfähigkeit von Entwicklerplattformanbietern im Laufe der Zeit verbessert werden kann.