Een selfservicebasis voor ontwikkelaars ontwerpen

Zodra u een goed begrip hebt van uw doel voor uw technische systemen, kunt u beginnen met het creëren van geavanceerdere selfservice-ervaringen voor ontwikkelaars. In deze sectie beschrijven we een conceptuele architectuur voor het bouwen of evalueren van producten die een flexibele basis vormen voor het maken ervan. We verwijzen naar deze concepten, patronen en onderdelen, gezamenlijk, als een selfservicebasis voor ontwikkelaars.

Hoewel u mogelijk niet alles nodig hebt wat hier in uw organisatie wordt beschreven, moet u rekening houden met deze concepten als u iets aangepasts bouwt of gerelateerde producten evalueert. In uw wereld kan dit model bestaan uit een combinatie van eigen geteelde, standaard en opensource-producten. Producten of opensource-portal-toolkits, zoals Backstage.io , kunnen verschillende termen gebruiken voor sommige elementen van het model die in deze sectie worden beschreven, maar het model kan u nog steeds helpen om u te oriënteren.

Goals en overwegingen

Het belangrijkste doel voor uw inspanningen op dit gebied moet zijn om selfservice met kaders mogelijk te maken door middel van gecontroleerde, beheerde taakuitvoering en inrichting, samen met gecentraliseerde zichtbaarheid. De gebieden die vaak het meest waardevol zijn om u op te richten, zijn de gebieden die omslachtig zijn of dingen zijn die de ontwikkelaar niet zelf kan doen vanwege complexiteit of machtigingen. Dit laatste deel is belangrijk om u in staat te stellen het principe van minimale bevoegdheden te volgen zonder ontwikkelaars door een handmatig servicedeskproces te dwingen.

Hoewel u ervoor kunt kiezen om uw DevOps-suite uit te breiden om aan deze behoeften te voldoen, moet u waarschijnlijk in de loop van de tijd meerdere toepassingsplatforms ondersteunen en moeten de specifieke hulpprogramma's en processen die deze ondersteunen, ook worden gewijzigd. Het belangrijkste probleem is dat uw standaarden een bewegend doel zijn. Zoals een platformtechnist het volgende heeft gezegd:

De moeilijkheden hebben betrekking op standaardisatie ... en omgaan met 'abandonware'... Standaardisatie wordt vaak niet bereikt vanwege mogelijke onderbrekingen van geautomatiseerde processen en de tijdrovende taak om noodzakelijke wijzigingen te identificeren. - Martin, DevOps Engineer, groot logistiek bedrijf

Zoals in dit citaat wordt benadrukt, is snel overschakelen naar een nieuwe of bijgewerkte standaard doorgaans niet haalbaar en brengt het verlaten van bestaande processen risico's met zich mee. Uw organisatie gebruikt mogelijk al meerdere DevOps-suites of verschillende combinaties van afzonderlijke hulpprogramma's en ontwikkelaarsservices per scenario. Zelfs met een centraal team en een standaardoplossing is variabiliteit onvermijdelijk naarmate uw selfservicebehoeften toenemen. U wilt dus gecontroleerde experimenten mogelijk maken, waarbij aangewezen teams nieuwe technologieën, implementatiestrategieën, enzovoort kunnen uitproberen, gevolgd door opzettelijke acceptatie en een incrementele implementatie.

Over het algemeen vallen selfservice-ervaringen in twee primaire categorieën:

• Automatisering
• Gegevensaggregatie

Hoewel gegevensaggregatie goede gebruikerservaringen creëert, zoals een platformtechnist het uitsprak:

Automatisering is de sleutel en zal door iedereen geliefd zijn. [Gegevens] aggregatie is secundair. – Peter, platform engineering lead, multinational tech bedrijf

Daarom is het waarschijnlijk dat het platform-engineeringtraject dat u in kaart hebt gebracht, enkele problemen heeft geïdentificeerd die door automatisering kunnen worden opgelost. Automatisering kan er niet alleen voor zorgen dat de cognitieve belasting en de taak van ontwikkelaars worden verminderd, maar ook dat toepassingen zijn verbonden met de beste hulpprogramma's en services voor bewerkingen, beveiliging en andere rollen om hun werk te doen.

Als u echter met meer dan één systeem werkt om uw automatisering te stimuleren, is een bepaald niveau van gegevensaggregatie handig om geautomatiseerde aanvragen en de bijbehorende resultaten bij te houden. U kunt vaak beginnen met een koppeling naar externe systemen om te voldoen aan andere behoeften of om in te zoomen op details. Gegevensaggregatie en zichtbaarheid zijn ook belangrijk voor controle, governance en het verminderen van verspilling (bijvoorbeeld: ongebruikte omgevingen).

Het automatiseren van dingen zoals het inrichten van de infrastructuur kan worden gedaan met behulp van systeemintegraties, maar u kunt ook een handmatig werkstroomproces activeren en faciliteren dat geautomatiseerd is voor de ontwikkelaar. Dit is handig in de vroege fasen van uw platform, voor nieuwe producten die u in uw ecosysteem wilt opnemen of op gebieden die u niet hebt of niet kunt automatiseren met behulp van een systeem (bijvoorbeeld toewijzing van softwarelicenties). Met het juiste ontwerp kunt u beginnen met een handmatig proces dat wordt gefaciliteerd door iets als Power Automate dat u na verloop van tijd overschakelt naar een volledig geautomatiseerde stroom. Ontwerp dus vanaf het begin voor een automatisering.

Gezien een productmentaliteit en het idee van een thinnest viable platform (TVP) (een MVP voor uw platform), moet u eenvoudig beginnen met het opnieuw gebruiken van bestaande investeringen, zoals uw technische systemen of een interne portal, en vervolgens CLIs, basiswebpagina's of zelfs Power Pages, Power BI- of Microsoft Fabric-dashboards maken en uitbreiden naarmate de behoefte zich voordoet. Met dat in gedachten kan een consistente API die UX vervolgens gebruikt, u helpen meerdere interfaces in de loop van de tijd te ondersteunen als uw behoeften en voorkeuren veranderen.

Overzicht van concepten

Bekijk de volgende afbeelding:

Zoals in de afbeelding wordt weergegeven, vormen de volgende onderdelen de kern van het concept van een selfservicebasis voor ontwikkelaars:

Component	Beschrijving
Api voor ontwikkelaarsplatform	Dit is uw single point of contact voor gebruikerservaringen. Het is in feite het contract van het systeem met andere systemen.
Grafiek voor ontwikkelaarsplatform	Een beheerde en veilige gegevensgrafiek waarmee u verschillende soorten entiteiten en sjablonen kunt detecteren, koppelen en gebruiken. Een entiteit is een object dat gegevensaggregatie uit meerdere bronnen mogelijk maakt, terwijl sjablonen gebruikersinvoer stimuleren die automatisering mogelijk maakt.
Orchestrator voor ontwikkelaarsplatform	Een mogelijkheid waarmee aanvragen op basis van sjablonen worden gerouteerd en bijgehouden om acties uit te voeren in een systeem of via een handmatig proces. Deze aanvragen worden doorgestuurd naar een van de platformproviders voor ontwikkelaars die kunnen worden geïntegreerd met een willekeurig aantal verschillende werkstroomsystemen of andere services.
Platformproviders voor ontwikkelaars	Een set onderdelen die logica inkapselen die nodig is om te integreren met downstreamsystemen ter ondersteuning van CRUD-bewerkingen op entiteiten en/of uitvoering van op sjablonen gebaseerde actieaanvragen. Elke provider kan een eigen specifiek type sjablonen ondersteunen en unieke of algemene typen entiteiten verzenden.
Metagegevens van gebruikersprofielen en team	Een mogelijkheid om informatie te behouden over een set personen die zijn gekoppeld aan een conceptueel team voor groepering en toegang tot de API voor het ontwikkelaarsplatform. De gebruiker is nauw gekoppeld aan een id-provideraccount (bijvoorbeeld Microsoft Entra ID aanmelden), maar zowel de gebruiker als een team kunnen worden gekoppeld aan een willekeurig aantal gerelateerde downstreamsysteemweergaven. Een implementatie van dit informatiearchief is het opnieuw gebruiken van de grafiek voor het ontwikkelaarsplatform. De selfservicebasis voor ontwikkelaars kan een gemeenschappelijk entiteitstype instellen voor zowel een gebruiker als een team en die informatie in de grafiek behouden. We houden deze winkel echter voor de duidelijkheid hier gescheiden.

Met deze basisonderdelen kunt u verschillende bouwstenen in de loop van de tijd gebruiken en uitwisselen. In de volgende secties gaan we dieper in op elk van deze opties.

Moet ik dit allemaal bouwen om aan de slag te gaan?

No. Ten eerste is dit een conceptueel model om u te helpen nadenken over wat een dergelijke basis moet kunnen doen wanneer dit is gebeurd. Ten tweede zijn de implementatiedetails hier minder belangrijk, aangezien de API voor het ontwikkelaarsplatform uw belangrijkste interface wordt. Uw eerste implementatie kan beginnen met het gebruik van interfaces en klassen in uw code voor de verschillende lagen die worden beschreven of in andere producten worden vermengd. U kunt ook aspecten weglaten omdat uw klantontwikkeling aangeeft dat het gewoon een lagere prioriteit heeft. Begin met wat je hebt en groei.

Met dat in gedachten, gaan we dieper ingaan op elk stuk.

Api voor ontwikkelaarsplatform

U moet een API voor het ontwikkelaarsplatform definiëren om te fungeren als het contract van uw systeem. De API wordt gebruikt door verschillende gebruikersinterfaces om gegevenstoegang in te schakelen of inrichting en andere acties te stimuleren.

Deze API moet ook fungeren als een belangrijke verificatie- en beveiligingslaag door de toegang tot onbewerkte onderliggende API's in andere systemen te beperken tot specifiekere, beheerde gegevens en bewerkingen. De API biedt toegang tot een eigen weergave van een gebruikersprofiel, de rol op hoog niveau van een gebruiker binnen het platform (teamlid, beheerder, enzovoort) en systeem-id's van de primaire id-provider. Zie Gebruikers en teams voor meer informatie.

Platformproviders voor ontwikkelaars

Gezien de breedte van een intern ontwikkelaarsplatform raden we u aan systemen te maken of te zoeken die een uitbreidbaar providermodel volgen om functionaliteit in de API te introduceren. Het idee is dat belangrijke functionaliteit zoals automatisering en gegevensaggregatie wordt geboden door interactie met pluggable onderdelen met goed gedefinieerde interfaces. Met deze losse koppeling kunt u stapsgewijs inschakelen wat u nodig hebt en verbetert de onderhoudbaarheid, omdat u de functionaliteit onafhankelijk van de rest van de basis kunt testen.

Het is ook een belangrijke manier om een schaalbare innerlijke bronmentaliteit voor uw platform mogelijk te maken. Doorgaans krijgen interne sourcing-inspanningen rond platform engineering geen grip vanwege uitdagingen met doorlopend onderhoud. Andere teams zijn misschien bereid om functionaliteit bij te dragen, maar zijn minder geneigd om iets in de kern van uw platform te onderhouden en te testen. Daarentegen heeft elk gecentraliseerd team beperkte capaciteit om bijgedragen code te onderhouden of zelfs pull-aanvragen te beoordelen. Het concept van een provider van het ontwikkelaarsplatform vermindert deze spanning door onafhankelijk geschreven code toe te staan om in te voegen op kernfunctionaliteit binnen de selfservicebasis van uw ontwikkelaar. Hoewel u zorgvuldig moet beheren welke providers u gebruikt, eventuele providercode moet controleren en de oppervlakte waartoe een bepaalde provider toegang heeft in uw ontwikkelaarsplatform moet beperken, kan een pluggable-benadering u helpen meer gedaan te krijgen door de inspanningen te schalen in een breder deel van de organisatie.

Belangrijke concepten van platformproviders voor ontwikkelaars

Entiteiten

Het concept van een entiteit is iets dat een ontwikkelaar of ander systeem in uw interne ontwikkelaarsplatform moet bijhouden, bijwerken, presenteren of erop reageren. Entiteiten kunnen relaties met elkaar hebben die, wanneer ze samen worden genomen, een grafiek vormen die essentiële informatie biedt over onderdelen van uw interne ontwikkelaarsplatform. Ontwikkelaarsplatformproviders kunnen vervolgens entiteiten uitvoeren om kernmogelijkheden mogelijk te maken, waaronder:

• Extern ingerichte resources/omgevingen of beschikbare API's voor detectie en gebruik beschikbaar maken
• Relaties beschikbaar maken voor afhankelijkheidsanalyse, impactanalyse, detectie, enzovoort.
• Onderhouder-/eigendomsgegevens voor detectie en samenwerking weergeven
• Meer gegevens beschikbaar maken voor gebruik in gebruikerservaringen

Het inkapselen van deze functionaliteit in een goed gedefinieerde interface voor ontwikkelaarsplatformprovider vereenvoudigt de integratie en het testen, maakt onafhankelijke implementatie mogelijk en stelt ontwikkelaars buiten het primaire interne platformteam in staat om providers bij te dragen en te beheren. Dit is belangrijk in grote of divisieorganisaties waar niet alle hulpprogramma's, services of platformen centraal worden beheerd, maar de bredere organisatie nog steeds mogelijkheden wil delen. Dus zelfs als u in eerste instantie niet op dit pad gaat, is het iets om over na te denken op de lange termijn.

Algemene eigenschappen

Elke entiteit moet een set gemeenschappelijke eigenschappen hebben, zodat de foundation deze kan beheren. Enkele eigenschappen die u moet overwegen, zijn onder andere:

• Unieke id
• Naam
• Oorspronkelijke provider
• Optionele koppelingen naar:
  • Eigenaar van gebruiker
  • Team dat eigenaar is
  • Andere entiteiten

De gebruikers- en teameigenschappen zijn om drie redenen belangrijk: op rollen gebaseerd toegangsbeheer (RBAC), detectie en gegevensaggregatie (zoals samenvattingen op teamniveau). Het vanaf het begin inbouwen in RBAC is essentieel voor de beveiliging en het laten groeien van uw interne ontwikkelplatform in de loop van de tijd. Aangezien ontwikkeling een teamsport is, wordt het snel essentieel om te ontdekken met wie u over een entiteit moet praten voor hergebruik, ondersteuning en innersourcing.

Algemene en providerspecifieke entiteiten

U moet ook een set genormaliseerde entiteiten op hoog niveau kunnen instellen die door meerdere providers kunnen worden uitgevoerd. Bijvoorbeeld:

• Omgevingen
• Middelen
• Apis
• Repositories
• Onderdelen
• Tools

Deze moeten over het algemeen op een hoog niveau zijn, zoals u in de C4-modelcontext of op hooguit onderdeeldiagrammen op hoog niveau zou plaatsen. Voor een omgeving hoeft u bijvoorbeeld niet de details van de interne infrastructuurtopografie op te nemen: u hebt alleen voldoende informatie nodig om verschillende conceptuele omgevingen van meerdere providers in dezelfde UX weer te geven en te koppelen. De entiteit kan verwijzen naar lagere detailniveaus buiten het systeem in plaats van alles te verbruiken. Deze bieden uitgangspunten voor detectie die centraal staan bij het inschakelen van gegevensaggregatie in de loop van de tijd.

Andere zijn specifiek voor een bepaalde use-case of provider, dus u moet nadenken over hoe u in de loop van de tijd een groeiende set entiteitstypen kunt gebruiken.

Sjablonen

Het concept van een sjabloon in deze context wijkt af van het idee van entiteiten omdat ze bedoeld zijn om een actie aan te sturen. Voorbeelden van scenario's zijn het inrichten van infrastructuur, het maken van een opslagplaats en andere langlopende processen. Deze sjablonen moeten ook beschikbaar zijn via uitbreidbare ontwikkelaarsplatformproviders en moeten dezelfde algemene eigenschappen ondersteunen als entiteiten, inclusief entiteitskoppelingen.

Ze kunnen echter ook de vereiste invoer definiëren, ongeacht of het systeem of de gebruiker is opgegeven, die nodig zijn om de actie uit te voeren. Deze kunnen variëren van de naamgeving van de resource tot optionele toevoegingen.

Voorbeelden van sjablonen zijn:

• IaC-sjablonen (Infrastructure-as-Code)
• Toepassingssjablonen (rechts beginnen) of sjabloonopslagplaatsen
• Pijplijn-/werkstroomsjablonen bouwen
• Implementatiepijplijn/werkstroomsjablonen
• Geparameteriseerde scripts
• Geparameteriseerde Power Automate-stromen (voorbeeld: een door EEN HTTP-aanvraag geactiveerde cloudstroom)
• Email sjablonen

Net als entiteiten kunnen sjablonen providerspecifieke eigenschappen bevatten.

Elke sjabloon kan een andere weergave hebben die uniek is voor de provider. Deze kunnen variëren van Terraform- of ARM-sjablonen tot Helm-grafieken, geparameteriseerde GitHub Actions werkstromen of Azure Pipelines, eenvoudige scripts of aangepaste indelingen.

De werkelijke onderliggende sjabloondetails hoeven niet per se centraal te worden opgeslagen. Ze kunnen zich in verschillende opslagplaatsen, registers of catalogi bevinden. U kunt bijvoorbeeld GitHub-sjabloonopslagplaatsen gebruiken voor uw toepassingssjablonen , terwijl uw IaC-sjablonen kunnen bestaan in een beperkte catalogusopslagplaats waartoe ontwikkelaars alleen indirect toegang hebben via iets als Azure-implementatieomgevingen. Andere IaC-sjablonen kunnen worden opgeslagen in een OCI-artefactregister, zoals Helm-grafieken. In andere gevallen kan de sjabloon een verwijzing zijn naar een geparameteriseerd HTTP-eindpunt. Een platformprovider voor ontwikkelaars moet precies voldoende informatie verstrekken over elk type sjabloon, zodat er naar kan worden verwezen en over eventuele opties die beschikbaar zijn voor gebruik in gebruikerservaringen. Maar de sjablonen zelf kunnen worden ondergebracht op de meest natuurlijke locatie voor uw gebruiksvoorbeelden.

Platformtechnici of experts op een bepaald gebied schrijven deze sjabloon en delen ze vervolgens met ontwikkelteams voor hergebruik. Het centraliseren van het gebruik van deze sjablonen via een systeem maakt selfservice voor ontwikkelaars mogelijk en creëert kaders die helpen bij het afdwingen van naleving van de normen of beleidsregels van de organisatie. Meer hierover wanneer we de orchestrator voor het ontwikkelaarsplatform een beetje behandelen.

De grafiek voor het ontwikkelaarsplatform

U kunt een grafiek voor het ontwikkelaarsplatform zien als iets waarmee u entiteiten en sjablonen van meerdere providers kunt koppelen aan een doorzoekbare grafiek. De werkelijke gegevens voor de entiteiten hoeven echter niet per se rechtstreeks in een grafiekspecifieke database te worden opgeslagen. In plaats daarvan kunnen interacties met providers in de cache worden opgeslagen, samen met de benodigde metagegevens, zodat ze allemaal bij elkaar passen.

De grafiek is krachtig wanneer het wordt gebruikt met algemene entiteiten die meerdere providers kunnen bijdragen. Een lijst met API's kan bijvoorbeeld afkomstig zijn van een product zoals Azure API Center, maar mogelijk wilt u ook automatisch invoeren in implementaties en omgevingen van uw continue implementatiesystemen. Na verloop van tijd kunt u schakelen tussen verschillende implementatiesystemen of zelfs meer dan één implementatiesysteem ondersteunen. Zolang elk implementatiesysteem een platformprovider voor ontwikkelaars heeft, moet u nog steeds de koppeling kunnen maken.

Elk van uw gebruikerservaringen die op basis van deze grafiek worden opgebouwd, kan vervolgens profiteren van een gemeenschappelijke API om detectie, zoeken, governance en meer mogelijk te maken. Een orchestrator voor het ontwikkelaarsplatform kan vervolgens profiteren van dezelfde grafiek, zodat acties die worden uitgevoerd door een provider van het ontwikkelaarsplatform automatisch entiteiten bijdragen die beschikbaar zijn voor dezelfde API.

Orchestrator voor ontwikkelaarsplatform

Met een orchestrator voor het ontwikkelaarsplatform kunnen ontwikkelaars of systemen aanvragen maken om een actie uit te voeren met behulp van een sjabloon. Het voert deze acties niet zelf uit, maar coördineert in plaats daarvan met een taakengine, werkstroomengine of een andere orchestrator om dit te doen. Het is een van de essentiële onderdelen waarvan u zeker wilt zijn dat deze deel uitmaakt van uw selfservicebasis. Hiermee kunnen ontwikkelaars aanvragen maken met een sjabloon of een actie uitvoeren zonder directe toestemming. Bovendien hoeven deze acties, in tegenstelling tot het concept van CI of CD, niet gerelateerd te zijn aan de broncode van de toepassing.

Zoals beschreven in Software Engineering-systemen toepassen, kunt u GitHub Actions, Azure Pipelines of een andere werkstroomengine als orchestrator gebruiken. Dit is een redelijke plaats om te beginnen, maar misschien wilt u een beetje abstractie hebben om verschillende typen sjablonen verschillende onderliggende engines te kunnen gebruiken. Dit kan handig zijn om een paar redenen:

• Ten eerste wilt u waarschijnlijk in de loop van de tijd verschillende werkstroom- en taakuitvoeringsengines kunnen kiezen zonder dat u flash cut hoeft te gebruiken. Door meer dan één engine toe te staan, kunt u in de loop van de tijd migreren of gewoon het gebruik van de nieuwe engine naar nieuwe acties zonder dat dit van invloed is op oudere.
• Voor sommige processen die u wilt helpen bij het organiseren, zijn in eerste instantie mogelijk handmatige stappen vereist, zelfs als u van plan bent ze later volledig te automatiseren.
• Andere acties zijn mogelijk gericht op rollen buiten het ontwikkelteam, zoals crediteuren of een licentiebeheerder. Engines met weinig code, zoals Power Automate, werken vaak goed voor deze rollen.
• Andere acties kunnen worden verwerkt via eenvoudige HTTP-aanvragen, waarbij het schalen van iets dat zo geschikt is als GitHub Actions of Azure Pipelines, niet nodig of rendabel is.

Gelukkig kan het uitbreiden van het idee van een platformprovider voor ontwikkelaars om het activeren en bijhouden van automatiseringsstappen te behandelen, deze benodigde abstractie bieden. Bekijk de volgende afbeelding:

Dit is het algemene concept:

1. Sjablonen kunnen desgewenst een set invoer opgeven die de gebruiker kan invoeren. Wanneer een ontwikkelaar een bepaalde actie activeert, kiezen ze een sjabloon (zelfs als deze niet op die manier wordt beschreven) en voeren ze eventuele invoer in.
2. Een verwijzing naar de sjabloongerelateerde invoer wordt een aanvraag in de api voor het ontwikkelaarsplatform.
3. Zodra een aanvraag is ingediend, begint een onderdeel voor het routeren en verwerken van aanvragen binnen de orchestrator met het bijhouden van de levenscyclus van de aanvraag. De sjabloon voor routering en verwerking van aanvragen in de aanvraag wordt doorgestuurd naar de platformprovider voor ontwikkelaars waarvan de sjabloon afkomstig is.
4. De provider van het ontwikkelaarsplatform voert vervolgens de juiste stappen uit voor de implementatie.
5. [Optioneel] De provider van het ontwikkelaarsplatform werkt de aanvraagstatus bij terwijl de actie wordt uitgevoerd.
6. Zodra aan de aanvraag is voldaan, kan de provider van het ontwikkelaarsplatform een set entiteiten retourneren om toe te voegen/bij te werken in de grafiek van het ontwikkelaarsplatform. Dit kunnen providerspecifieke of algemene entiteiten zijn.

Als u geavanceerdere interacties wilt ondersteunen, kunt u deze ontwikkelaarsplatformproviders toestaan om de API van het ontwikkelaarsplatform rechtstreeks aan te roepen om meer entiteiten als invoer op te halen of zelfs een andere gerelateerde actie aan te vragen.

Hoewel de specifieke oplossing of een product dat u evalueert, kan variëren, geeft dit u een idee van de kwaliteiten die u moet zoeken.

Met dit in gedachten wilt u een platformprovider voor ontwikkelaars hebben die gebruikmaakt van een algemene taak- of werkstroomengine. Meer in het bijzonder wilt u iets dat een brug vormt tussen wat u hebt samengesteld als onderdeel van Software Engineering-systemen toepassen. Een algemene engine voor werkstroom of taakuitvoering waarin u waarschijnlijk zult investeren, is uw CI/CD-systeem.

Een voorbeeld met GitHub Actions of Azure Pipelines

Laten we eens kort kijken hoe een GitHub Actions of Azure Pipelines als provider van het ontwikkelaarsplatform zou werken.

Voor GitHub Actions is het belangrijk dat een provider van het ontwikkelaarsplatform verbinding kan maken met het opgegeven GitHub-exemplaar en de ACTIONS REST API kan gebruiken om een gebeurtenis voor het verzenden van een werkstroom te starten om een werkstroomuitvoering te activeren. Elke werkstroom kan een set invoer ondersteunen door een workflow_dispatch-configuratie toe te voegen aan het YAML-bestand van de werkstroom. Azure DevOps-triggers zijn vergelijkbaar en u kunt ook de Azure DevOps Pipeline-API gebruiken voor uitvoeringen. U ziet waarschijnlijk dezelfde mogelijkheden in andere producten.

Deze werkstromen/pijplijnen hoeven zich niet in opslagplaatsen voor broncode van toepassingen te plaatsen. Het concept zou zijn om gebruik te maken van dit feit om iets als dit te doen:

1. Platformtechnici of DevOps-teamleden kunnen de werkstromen/pijplijnen onderhouden in een of meer centrale opslagplaatsen waartoe ontwikkelaars zelf geen toegang hebben, maar de provider van het ontwikkelaarsplatform is ingesteld voor gebruik. Dezezelfde opslagplaats kan scripts en IaC-fragmenten bevatten die door de werkstromen/pijplijnen worden gebruikt.
2. Als u deze werkstromen/pijplijnen wilt laten communiceren met het juiste downstreamsysteem, kunnen ops of andere leden van uw platform engineeringteam de benodigde geheimen toevoegen in de centrale opslagplaats. Zie GitHub Actions- en Azure DevOps-documentatie voor meer informatie over hoe u dit doet, of u kunt ervoor kiezen om de geheimen te centraliseren met behulp van iets als Azure Key Vault.
3. Deze werkstromen/pijplijnen kunnen vervolgens een model volgen waarin ze alle resulterende entiteiten publiceren als een build-/implementatieartefact (GitHub-docs, Azure DevOps-documenten).
4. Tijdens een uitvoering kan de provider van het ontwikkelaarsplatform vervolgens de status van de werkstroom/pijplijn watch en de levenscyclusstatus in de orchestrator bijwerken totdat deze is voltooid. U kunt bijvoorbeeld webhook gebruiken met GitHub Actions en service hooks met Azure Pipelines om updates bij te houden.
5. Zodra dit is voltooid, kan de provider het gepubliceerde artefact gebruiken voor opname in de grafiek van het ontwikkelaarsplatform, indien nodig.

Ten slotte kunt u deze provider van het ontwikkelaarsplatform instellen om een set sjablonen uit te voeren in de grafiek van het ontwikkelaarsplatform die verwijzen naar de juiste opslagplaats en werkstroom/pijplijn, samen met invoer voor een bepaalde taak.

Het mooie van het gebruik van uw CI/CD-systeem is dat ze vaak zijn ingesteld om het uitvoeren van willekeurige CLI's te ondersteunen, zodat u geen unieke, eersteklas integratie nodig hebt voor alles wat u doet. U kunt deze naar behoefte in de loop van de tijd toevoegen.

Veel van wat in dit voorbeeld wordt beschreven, is van toepassing op de werking van andere typen providers. Het is ook belangrijk om te weten dat het gebruik van GitHub Actions of Azure-pijplijnen in deze context niet vereist dat u deze ook gebruikt voor uw werkelijke CI/CD-pijplijnen.

Andere voorbeelden

Hier volgen enkele voorbeelden van andere typen ontwikkelaarsplatformproviders die sjablonen kunnen verwerken.

Voorbeeld	Beschrijving
Bewerkingen voor broncodebeheer	In sommige gevallen moet u mogelijk een opslagplaats maken of bijwerken, een pull-aanvraag indienen of een andere bewerking met betrekking tot broncodebeheer uitvoeren. Hoewel algemene asynchrone werkstroomengines dit soort bewerkingen kunnen beheren, kan het handig zijn om eenvoudige Git-bewerkingen zonder één bewerking uit te voeren.
Inrichtingsfuncties voor infrastructuur	Hoewel GitHub Actions en Azure Pipelines goed werken voor het beheren van infrastructuurinrichting, kunt u ook kiezen voor meer directe integraties. Een toegewezen provider kan de installatie stroomlijnen en overhead voorkomen. Services zoals Azure-implementatieomgevingen of Terraform Cloud zijn meer direct gericht op het veilig en veilig inrichten van IaC-sjablonen. Andere voorbeelden zijn bijvoorbeeld het maken van Kubernetes-naamruimten voor toepassingen in gedeelde clusters of het gebruik van Git met GitOps-werkstromen met Flux of Argo CD als een specifiek type provider. Nog meer app-gerichte modellen, zoals het experimentele Radius OSS-incubatieproject met hun eigen CLIs, kunnen na verloop van tijd hun eigen ontwikkelaarsplatformproviders krijgen. Het belangrijkste is om uitbreidbaarheid te zoeken en te plannen, zodat u zich kunt aanpassen.
Toepassingssteiger /seeding	Toepassingssjablonen zijn een belangrijk onderdeel van waar platformengineering in de loop van de tijd toe leidt. U kunt de sjabloonengine van uw keuze ondersteunen door een toegewezen platformprovider voor ontwikkelaars te bieden die niet alleen is ontworpen om een toepassingsbronstructuur uit te werken, maar ook inhoud te maken en naar een broncodeopslagplaats te pushen en de resulterende entiteiten toe te voegen aan de grafiek. Elk ecosysteem heeft zijn eigen voorkeur voor toepassingsopstellingen, of het nu Yeoman, cookiecutter of iets als de Azure Developer CLI is, zodat u met het providermodel hier meer dan één van dezelfde interfaces kunt ondersteunen. Ook hier is de uitbreidbaarheid belangrijk.
Handmatige processen	Of het nu gaat om het automatisch genereren van een pull-aanvraag voor handmatige goedkeuring of handmatige werkstroomstappen voor niet-ontwikkelaars om te reageren op het gebruik van iets als Power Platform, hetzelfde model op basis van sjablonen kan worden gebruikt in een platformprovider voor ontwikkelaars. U kunt zelfs in de loop van de tijd naar meer geautomatiseerde stappen gaan.

Hoewel u mogelijk niet al deze providers nodig hebt om aan de slag te gaan, kunt u zien hoe uitbreidbaarheid via zoiets als een ontwikkelaarplatformprovider uw automatiseringsmogelijkheden in de loop van de tijd kan helpen groeien.

Gebruikers en teams

Platform engineering is inherent aan meerdere systemen, dus het is belangrijk om te plannen hoe een selfservicebasis de meer uitdagende problemen met het integreren van deze systemen moet aanpakken. In deze sectie behandelen we een strategie voor het aanpakken van veelvoorkomende uitdagingen met identiteit, gebruikers en teams.

Bekijk eerst deze twee aanbevelingen:

Aanbeveling	Beschrijving
De API voor het ontwikkelaarsplatform rechtstreeks integreren met uw id-provider voor optimale beveiliging	Om de API voor het ontwikkelaarsplatform te beveiligen, raden we directe integratie aan met een id-provider zoals Microsoft Entra ID gezien de robuuste identiteit en de mogelijkheden van Op rollen gebaseerd toegangsbeheer (RBAC) van Entra ID. Er zijn veel voordelen aan het rechtstreeks gebruik van de systeemeigen SDK's en API's van een id-provider (bijvoorbeeld via MSAL Entra ID) in plaats van via een abstractie. U kunt end-to-end-beveiliging stimuleren en overal op hetzelfde RBAC-model vertrouwen, terwijl u ervoor zorgt dat het beleid voor voorwaardelijke toegang voortdurend wordt geëvalueerd (in tegenstelling tot alleen op het moment van aanmelding).
Integraties van groepen voor eenmalige aanmelding en id-providers gebruiken in downstreamsystemen	Uw integraties voor eenmalige aanmelding (SSO) moeten gebruikmaken van dezelfde id-provider en tenant die u gebruikt voor uw ontwikkelaarsplatform-API. Zorg er ook voor dat u profiteert van ondersteuning voor protocollen zoals SCIM voor bedrading in id-providergroepen (zoals AD-groepen). Het koppelen van deze id-providergroepen aan downstreamsysteemmachtigingen is niet altijd automatisch, maar u kunt minimaal handmatig id-providergroepen koppelen aan de groeperingsconcepten van elk hulpprogramma zonder het lidmaatschap achteraf handmatig te beheren. U kunt bijvoorbeeld de EMU-ondersteuning ( Enterprise Managed User ) van GitHub combineren met handmatig profiteren van de mogelijkheid om groepen van id-providers te koppelen aan GitHub-teams. Azure DevOps heeft vergelijkbare mogelijkheden.

Vervolgens bouwen we op basis van deze aanbevelingen op om een model te maken voor het afhandelen van meer uitdagende problemen op dit gebied.

Het concept van een team buiten één id-providergroep instellen

Naarmate uw platformtechniek verdergaat, zult u waarschijnlijk merken dat id-providergroepen geweldig zijn voor het beheren van lidmaatschappen, maar dat meerdere groepen echt samen moeten komen om het concept van een team te vormen voor op rollen gebaseerd toegangsbeheer (RBAC) en gegevensaggregatie.

In de context van platform engineering definiëren we een team als een set mensen met verschillende rollen die samenwerken. Voor gegevensaggregatie is het idee van een team met meerdere rollen essentieel voor detectie en samenvoeging van informatie op plaatsen zoals rapportagedashboards. Aan de andere kant is een groep een algemeen id-providerconcept voor een set gebruikers en is ontworpen met het idee om meerdere personen toe te voegen aan een specifieke rol, in plaats van andersom. Met RBAC kan een team zich daarom verhouden tot meerdere id-providergroepen via verschillende rollen.

De bron van uw teamgegevens kan afkomstig zijn van een paar verschillende locaties. Als u bijvoorbeeld teams als codepatroon (TaC) gebruikt, kan een provider van het ontwikkelaarsplatform watch voor bestandswijzigingen in een opslagplaats en deze opslaan in een gebruikersprofiel en metagegevensarchief van het team. U kunt ook rechtstreeks integreren met iets als een Azure Dev Center-project waarvoor deze kern-RBAC-constructies al beschikbaar zijn.

Een model tot stand brengen voor integratie met downstreamsystemen op team- of gebruikersniveau

Hoewel sommige hulpprogramma's en services voor ontwikkelaars en bewerkingen systeemeigen worden geïntegreerd en rechtstreeks gebruikmaken van identiteitsproviderconcepten, zullen velen dit abstraheren in hun eigen weergave van een groep of gebruiker (zelfs met eenmalige aanmelding). Naast het inschakelen van toegang tot hulpprogramma's, kan deze realiteit ook problemen opleveren voor gegevensaggregatie. Het is met name mogelijk dat API's in het downstreamsysteem hun eigen id's gebruiken in plaats van id-provider-id's (bijvoorbeeld: de object-id in Entra ID wordt niet rechtstreeks gebruikt). Dit maakt het filteren en koppelen van gegevens op gebruikers- of teamniveau lastig, tenzij u verschillende id's kunt toewijzen.

Verschillen in team- en groepsniveaus aanpakken

Met patronen zoals TaC kunt u relaties tussen de team- of groeps-id's van elk systeem opslaan en openen, zodat u ertussen kunt toewijzen. Samengevat wordt een beveiligde, controleerbare Git-opslagplaats de bron van een team en pull-aanvragen bieden een beheerde gebruikersinterface om updates uit te voeren. CI/CD-systemen kunnen vervolgens downstreamsystemen bijwerken en de gerelateerde id-relaties behouden voor het team dat hiervoor is gebruikt.

Hierdoor kunnen bijvoorbeeld de volgende relaties worden opgeslagen voor in API-aanroepen:

Als u liever een andere gegevensbron gebruikt dan bestanden in een opslagplaats van uw teams, kan hetzelfde algemene concept worden toegepast met behulp van de orchestrator voor het ontwikkelaarsplatform om hetzelfde te bereiken. Onder dit model kan een platformprovider voor ontwikkelaars voor de bron van de teamgegevens een teamupdate-gebeurtenis activeren die alle andere providers ontvangen en waar nodig op reageren.

Problemen met gebruikers-id's oplossen

Een andere gerelateerde uitdaging voor gegevenstoegang en -aggregatie zijn verschillen tussen gebruikers-id's. Net als in het geval van het team, als u een systeem-naar-systeem-integratie gebruikt om gegevens over een gebruiker op te vragen, kunt u er niet van uitgaan dat de systeemeigen id van id-providers (bijvoorbeeld object-id voor Entra ID) een bepaalde API ondersteunt. Ook hier kan het helpen om een toewijzing op te slaan voor een gebruikers-id die toegang heeft tot gegevens via de API voor het ontwikkelaarsplatform. Neem bijvoorbeeld GitHub:

Als u voor elk systeem een gebruikers-id van een ander systeem kunt opzoeken via een API zonder een gebruikerstoken, kan een bepaalde provider van het ontwikkelaarsplatform deze toewijzing onmiddellijk genereren. In sommige gevallen kan dit ingewikkeld worden, omdat u deze bewerking mogelijk bulksgewijs moet uitvoeren en de resultaten in de cache moet opslaan voor verwijzing om de prestaties te behouden.

Terugvallen op het gebruik van meerdere gebruikerstokens

Voor situaties waarin providers toegang moeten hebben tot gegevens op gebruikersniveau zonder dat er een manier is om gebruikers-id's te vertalen die zou werken, kan de API voor het ontwikkelaarsplatform worden ingesteld voor het beheren van meerdere gebruikerstokens. Bijvoorbeeld:

1. De API voor het ontwikkelaarsplatform kan ondersteuning bieden voor een cache van providerspecifieke gebruikerstokens voor gebruik met downstreamsystemen.
2. Interacties met een bepaalde provider die door de API worden geactiveerd, worden opgenomen in het gebruikerstoken van de provider, indien beschikbaar.
3. Om het geval af te handelen waarbij geen gebruikerstoken beschikbaar was, activeert de provider een OAuth-stroom om er een op te halen.
4. Om te beginnen geeft de API van het ontwikkelaarsplatform een verificatie-URI door voor een OAuth-stroom met een omleidings-URI die is doorgegeven aan de provider. De doorgegeven URI bevat een nonce/eenmalige gebruikscode.
5. De API retourneert vervolgens een 'niet geverifieerd' antwoord met de URI.
6. Elke UX kan deze URI vervolgens gebruiken om de juiste verificatiestroom in een browser aan te drijven.
7. Zodra de omleiding plaatsvindt, ontvangt het ontwikkelaarsplatform het benodigde gebruikerstoken en slaat het dit in de cache op voor toekomstig gebruik, samen met de gebruikers-id.
8. De client kan vervolgens de API-aanroep opnieuw proberen, wat dan slaagt.

Dit concept beschrijft een manier om om te gaan met gecompliceerde verificatie, omdat u id's waar mogelijk opnieuw kunt gebruiken en u geen afzonderlijke omleidings-URI's per downstreamsysteem hoeft te onderhouden.

Gegevens samenvoegen en extra mogelijkheden bieden

Contextbewuste dieptekoppelingen naar hulpprogramma's en rapportagesystemen gebruiken

Tot nu toe hebben we het gehad over het automatiseringsaspect van de probleemruimte. Dit kan alleen al een lange weg zijn, omdat uw gebruikersinterface waarden in de entiteiten kan gebruiken die tijdens de automatisering worden geretourneerd om dieptekoppelingen naar andere systemen voor het team te maken.

Zelfs als er geen sprake is van automatisering, kunnen ontwikkelaarsplatformproviders elk soort entiteitsbehoefte verzenden. Over het algemeen wilt u echter niet alle gedetailleerde gegevens van uw hele interne ontwikkelplatform in uw grafiek voor het ontwikkelaarsplatform opnemen. Dashboards in waarneembaarheidsoplossingen zoals Grafana, Prometheus, DataDog of code-intelligentie in producten zoals SonarQube en systeemeigen mogelijkheden in DevOps-suites zoals GitHub en Azure DevOps zijn allemaal zeer geschikt. In plaats daarvan is de beste aanpak vaak om dieptekoppelingen naar deze andere systemen te maken. Uw entiteiten kunnen voldoende informatie bieden om koppelingen te maken zonder rechtstreeks gedetailleerde informatie te bevatten, zoals logboekinhoud.

Voor gevallen waarin u geaggregeerde en samengevatte gegevens in verschillende hulpprogramma's wilt gebruiken of aangepaste metrische gegevens wilt aandrijven, kunnen rapportageoplossingen Power BI of Microsoft Fabric uw volgende aanroeppoort zijn. Als u teamgegevens wilt samenvoegen, kunt u verbinding maken met de database van uw Foundation of een api voor het ontwikkelaarsplatform gebruiken. Zoals beschreven in Plannen en prioriteren, kunt u bijvoorbeeld een aangepast dashboard gebruiken om het succes van uw interne ontwikkelaarsplatform te meten.

Wees selectief met elke extra ervaring die u bouwt

Hoewel het aantrekkelijk kan zijn om bestaande mogelijkheden opnieuw te maken in iets als een algemene portal, moet u deze ook onderhouden. Dit is het gebied waar het volgen van een productmentaliteit belangrijk is. Dashboardstijlinterfaces zijn gemakkelijk te bedenken en te begrijpen, maar uw ontwikkelaars kunnen ergens anders meer waarde vinden.

Dat gezegd hebbende, kunt u met het model hier geaggregeerde gegevens in de grafiek van het ontwikkelaarsplatform gebruiken om aangepaste gebruikerservaringen te maken. Entiteiten moeten ingebouwde ondersteuning hebben, zodat ze kunnen worden gekoppeld aan een gebruiker of team. Hierdoor kan de API van uw ontwikkelaarsplatform uitvoer bereiken (samen met het gebruik van indexering en caching).

Maar zelfs wanneer u aangepaste UX moet maken in plaats van een dieptekoppeling, is het ophalen van alle gegevens in uw grafiek voor het ontwikkelaarsplatform doorgaans nog steeds niet de beste aanpak. Denk bijvoorbeeld aan een situatie waarin u mogelijk logboeken wilt weergeven in uw UX die al een goed gedefinieerde en beheerde startpagina hebben. Gebruik informatie in de gerelateerde entiteiten om uw gebruikersinterface te helpen gegevens rechtstreeks uit downstreamsystemen te verzamelen.

Om te beginnen moet u mogelijk een systeem-naar-systeem-integratie gebruiken om verbinding te maken, maar zodra u een van de modellen hebt geïmplementeerd die worden beschreven in gebruikers en teams, kunt u indien nodig alle opgeslagen downstreamgebruikers-/team-id's of tokens voor gebruikersverificatie gebruiken.

Hier volgen enkele voorbeelden van veelvoorkomende ervaringen die u kunt overwegen:

Voorbeeld	Beschrijving
Detectie en verkenning	Zoals een platformtechnisch beoefenaar het stelde: "Wat projecten vertraagt, is communicatie, niet ontwikkelaarsvaardigheden." –Daniel, Cloud Engineer, Fortune 500 Media Company. Omdat software een teamsport is, is het maken van een gebruikersinterface om teams en de entiteiten die ze bezitten te helpen ontdekken, meestal een van de eerste dingen die u moet aanpakken. Zoeken, ontdekken en documenten tussen teams helpen hergebruik te bevorderen en samenwerking te bevorderen voor interne sourcing of ondersteuning. Teams profiteren ook van een one-stop-shop om dingen te vinden waarvan ze eigenaar zijn, waaronder omgevingen, opslagplaatsen en andere resources, zoals documenten.
Handmatige registratie van omgevingen of resources	Hoewel veel dingen kunnen worden ingericht en bijgehouden via de orchestrator voor het ontwikkelaarsplatform, wilt u mogelijk ook resources of omgevingen registreren die al bestaan of nog niet zijn geautomatiseerd. Een eenvoudige provider die informatie uit een Git-opslagplaats haalt en informatie toevoegt aan resources/omgevingsbeheer, kan hier handig zijn. Als u al een softwarecatalogus hebt, wordt dit ook een manier om deze in het model te integreren.
Een API-catalogus	Het bijhouden van API's die ontwikkelaars moeten gebruiken, kan een heel eind komen. Als u nog niets hebt, kunt u zelfs beginnen met een eenvoudige Git-opslagplaats met een reeks bestanden die API's en hun status vertegenwoordigen. Gebruik pull-aanvragen om uw goedkeuringswerkstroom te beheren. Deze kunnen worden toegevoegd aan de grafiek van uw ontwikkelaarsplatform, zodat ze kunnen worden weergegeven of gekoppeld aan andere entiteiten. Voor krachtigere mogelijkheden kunt u bijvoorbeeld het API Center van Microsoft of een ander product integreren.
Licentienaleving	In sommige gevallen wilt u mogelijk ook inzicht geven in softwarelicentiecompatibiliteit en seatverbruik. Ontwikkelaarsplatforms kunnen ook de automatisering toevoegen die nodig is om seats te verbruiken, maar zelfs als seats handmatig worden toegewezen (bijvoorbeeld via een pr-proces in een Git-opslagplaats), krijgen ontwikkelaars inzicht in wat ze hebben (en de mogelijkheid van beheerders om alles te zien).
Een toepassingsgerichte weergave van Kubernetes	Wanneer u een gedeeld Kubernetes-cluster gebruikt, kan het moeilijk zijn voor ontwikkelaars om de status van hun toepassingen te vinden en te begrijpen via de UX van de clusterbeheerder. Verschillende organisaties hebben ervoor gekozen om dit probleem anders aan te pakken, maar het gebruik van een naamruimte om een toepassing weer te geven, is een bekende manier om dit te doen. Van daaruit kunt u entiteiten gebruiken om koppelingen tot stand te brengen tussen de naamruimte van de toepassing in het cluster en een team, en een meer ontwikkelaarsgerichte weergave van de status van de toepassing maken en dieptekoppelingen bieden naar andere hulpprogramma's of web-gebruikersinterfaces.

Gebruikerservaringen

Verschillende rollen in uw organisatie hebben hulpprogramma's of services die een zwaartepunt vormen voor hun dagelijkse werk. De aantrekkingskracht van deze systemen kan het moeilijk maken voor nieuwe gebruikerservaringen buiten deze zwaartepunten om tractie te krijgen. In een perfecte wereld kunnen ontwikkelaars, bewerkingen en andere rollen blijven werken in een omgeving die voor hen zinvol is, vaak de omgeving die ze al gebruiken.

Met dit in gedachten is het een goed idee om meerdere gebruikersinterfaces te plannen naarmate u verder gaat met uw platform engineeringtraject. Dit kan ook een kans bieden om eenvoudig te beginnen, waarde te bewijzen en te groeien naar complexere interfaces naarmate de behoefte zich voordoet.

Integreren wat u hebt

Als u de artikelen Software engineeringsystemen toepassen en Toepassingsplatform verfijnen hebt gelezen, hebt u waarschijnlijk de systemen geïdentificeerd die u wilt blijven gebruiken. In beide gevallen moet u evalueren of u wat u hebt kunt verbeteren en uitbreiden voordat u begint met het bouwen van nieuwe ervaringen. (Vraag uzelf af of mensen beter reageren op een andere nieuwe gebruikerservaring of een verbeterde versie van iets dat ze nu hebben?)

Sommige van de hulpprogramma's, hulpprogramma's of web-apps die u wilt blijven gebruiken, zijn aangepast en dit zijn goede kandidaten voor verbetering. Vergeet echter niet op te letten of uw favoriete hulpprogramma's en services een uitbreidbaarheidsmodel hebben dat u kunt gebruiken. Je hebt er veel voordeel van als je daar begint. Dit kan zorgen over onderhoud en beveiliging voorkomen en u zich richten op het probleem dat u probeert op te lossen

U kunt bijvoorbeeld de volgende oppervlakken uitbreiden die u al gebruikt:

• Editors en IDE's.
• Uw DevOps-suite.
• CLI's zijn ook steeds uitbreidbaarer.
• Omgevingen met weinig of geen code, zoals Power Pages.

Elke functie biedt mogelijk een beter uitgangspunt voor een bepaalde rol dan iets dat u helemaal zelf instelt, omdat het bestaande zwaartepunten zijn. Als u een algemene api voor het ontwikkelaarsplatform als basislijn hebt, kunt u dingen uitwisselen, experimenteren en in de loop van de tijd veranderen.

Webeditor-extensies overwegen om een ontwikkelaarsportal te maken

Als u op zoek bent naar een webervaring voor ontwikkelaars, moet u er rekening mee houden dat webversies van editors en IDE's een recente trend zijn. Veel, zoals degenen die VS Code gebruiken, hebben extensieondersteuning. Met VS Code wordt alles wat u voor deze webervaringen bouwt, lokaal vertaald voor een dubbel voordeel.

Naast services zoals GitHub Codespaces is vscode.dev een gratis webversie van de VS Code-editor zonder rekenkracht, maar biedt ondersteuning voor bepaalde typen extensies , waaronder extensies die gebruikmaken van webweergaven voor aangepaste gebruikersinterface.

Zelfs als uw ontwikkelaars VS Code zelf niet gebruiken, zijn de UX-patronen bekend en zijn ze te vinden in andere ontwikkelhulpprogramma's. Het gebruik van vscode.dev kan naast het hulpprogramma zelf een handige en vertrouwde webbasis bieden voor ontwikkelaarservaringen.

Deze kunnen fungeren als een op ontwikkelaars gerichte portal in een vertrouwde vorm die ook kan worden omgezet in lokaal gebruik.

ChatOps

Een andere kans die vaak over het hoofd wordt gezien, is het implementeren van een ChatOps-interface. Gezien de toename van op chat gebaseerde interfaces als gevolg van de opkomst van AI-producten zoals ChatGPT en GitHub Copilot, kunnen actieopdrachten of slash-opdrachten een handige manier zijn om automatiseringswerkstromen te activeren, de status te controleren en meer. Aangezien de meeste CI/CD-platformen voor toepassingen kant-en-klare ondersteuning bieden voor systemen zoals Microsoft Teams, Slack of Discord, kan dit een natuurlijke manier zijn om te integreren met andere gebruikersinterface-ontwikkelaars en gerelateerde bewerkingsrollen die dagelijks worden gebruikt. Bovendien hebben al deze producten een uitbreidbaarheidsmodel.

Investeren in een nieuwe ontwikkelaarsportal

Ervan uitgaande dat u geen bestaande portal of interface hebt die u als basis wilt gebruiken, kunt u besluiten om een nieuwe ontwikkelaarsportal te bouwen. Beschouw dit als een bestemming in plaats van een beginpunt. Als u nog geen ontwikkelteam hebt dat met u samenwerkt, is dit het moment om dit te doen. Elke organisatie is anders, dus er is geen one-size-fits-all antwoord voor wat in dit soort ervaring zou moeten zijn. Als gevolg hiervan is er geen defacto antwoord voor een voorverpakt product dat u kunt instellen en as-is gebruiken voor iets zoals dit vandaag.

Voor aangepaste zelf-hostende opties zijn algemene webportalframeworks niet nieuw en gebruiken uw ontwikkelteams mogelijk al een framework dat u kunt gebruiken. Als u probeert iets voor uw gebruikers te krijgen voor vroege feedback, kunt u zelfs beginnen met iets zo eenvoudig als de Power Pages met weinig code om verbinding te maken met de algemene ontwikkelaarsplatform-API.

Recentere inspanningen in de ontwikkelaarsportal zijn meer bevooroordeeld. Backstage.io is bijvoorbeeld een aangepaste toolkit voor de ontwikkelaarsportal die in eerste instantie is gebouwd om te voldoen aan de behoeften van Spotify. Het bevat een CLI om u te helpen bij het opstarten van uw bronstructuur, net zoals create-react-app voor React.js.

Als portal-toolkit is er werk nodig om aan de slag te gaan en aanpassing vereist kennis van TypeScript, Node.js en React. Het mooie van het is echter dat u als toolkit bijna alles kunt wijzigen. Het heeft ook zijn eigen softwarecatalogus en templating-mechanisme, maar hun gebruik is niet vereist, en het heeft een goed gedefinieerde manier om nieuwe 1^st en 3^rd party-code genaamd plug-ins te brengen.