Utforma en självbetjäningsgrund för utvecklare

När du har en god förståelse för ditt mål för dina tekniska system kan du skapa mer avancerade självbetjäningsupplevelser för utvecklare. En självbetjäningsupplevelse för utvecklare bygger på en grund av begrepp, mönster och komponenter.

Även om du kanske inte behöver allt som beskrivs här i din organisation idag bör du ha dessa begrepp i åtanke om du skapar något anpassat eller utvärderar relaterade produkter. Utvecklarens självbetjäningsmodell kan bestå av en kombination av hemodlade, färdiga produkter och produkter med öppen källkod. Produkter eller portalverktyg med öppen källkod som Backstage.io kan använda olika termer för vissa delar av modellen som beskrivs här, men modellen kan fortfarande hjälpa dig att orientera dig.

Automatisera arbetsflöden, aggregera data, starta enkelt och expandera gradvis

Målet är att möjliggöra självbetjäning med skyddsräcken genom kontrollerat, styrt tasksutförande och tillhandahållande, tillsammans med centraliserad synlighet. De områden som är mest värdefulla att fokusera på är de som antingen är omständliga eller är saker som utvecklaren inte kan göra själva på grund av komplexitet eller behörigheter. Den här sista delen är viktig för att du ska kunna följa principen om lägsta behörighet utan att tvinga utvecklare genom en manuell servicedeskprocess.

Även om du kan välja att utöka Din DevOps-svit för att uppfylla dessa behov, måste du förmodligen ha stöd för flera programplattformar över tid, och de specifika verktyg och processer som stöder dem kan också behöva ändras. Huvudfrågan är att dina standarder är ett rörligt mål. Som en plattformstekniker sa:

Svårigheterna innebär standardisering ... och hantera "abandonware"... Standardisering uppnås ofta inte på grund av potentiella avbrott i automatiserade processer och den tidskrävande uppgiften att identifiera nödvändiga ändringar. - Martin, DevOps-ingenjör, stort logistikföretag

Att snabbt byta till en ny eller uppdaterad standard är vanligtvis inte möjligt, och att överge befintliga processer skapar risk. Din organisation kanske redan använder flera DevOps-paket eller olika kombinationer av enskilda verktyg och utvecklartjänster efter scenario. Även med ett centralt team och en standardlösning, eftersom dina självbetjäningsbehov ökar, är variabilitet oundviklig. Därför vill du tillåta kontrollerade experiment där utsedda team kan prova nya tekniker, distributionsstrategier och så vidare, följt av avsiktlig implementering och inkrementell distribution.

I allmänhet finns självbetjäningsupplevelser i två primära kategorier: automatisering och dataaggregering.

Även om datasammansättning skapar bra användarupplevelser är automatisering viktigare:

Automatisering är nyckeln och kommer att älskas av alla. [Data] aggregering är sekundär. – Peter, plattformsingenjör, multinationellt teknikföretag

Under din plattformstekniska resa identifierade du problem som kan lösas av automatisering. Förutom att minska den kognitiva belastningen och utvecklararbetet kan automatisering också hjälpa till att säkerställa att programmen är anslutna till de bästa verktygen och tjänsterna för åtgärder, säkerhet och andra roller för att utföra sitt arbete.

Men om du arbetar med mer än ett system för att driva din automatisering är en viss nivå av dataaggregering användbar för att spåra automatiserade begäranden och tillhörande resultat. Du kan börja med att länka till externa system för att uppfylla andra behov eller för detaljerad information. Datasammansättning och synlighet är också viktigt för granskning, styrning och minskning av avfall (till exempel oanvända miljöer).

Automatisera saker som infrastrukturetablering kan göras med hjälp av systemintegreringar, men du kan också utlösa och underlätta en manuell arbetsflödesprocess som ser automatiserad ut för utvecklaren. Detta är användbart i de tidiga skedena av din plattform, för nya produkter som du tar in i ditt ekosystem, eller i områden som du inte har eller inte kan automatisera med hjälp av ett system (till exempel tilldelning av programvarulicenser). Med rätt design kan du börja med en manuell process som underlättas av något som liknar Power Automate som du växlar över till ett helt automatiserat flöde över tid. Designa därför för en automatisering från början.

Börja enkelt genom att återanvända befintliga investeringar som dina tekniska system eller en intern portal, gå sedan vidare till att skapa CLIs, grundläggande webbsidor eller till och med Power Pages, Power BI eller Microsoft Fabric-instrumentpaneler och expandera när behovet uppstår. Att ha ett konsekvent API som UX sedan använder kan hjälpa dig att stödja flera gränssnitt över tid när dina behov och inställningar ändras.

Komponenter för självbetjänings-plattform för utvecklare: API, graf, orkestrator, leverantörer och metadata

Överväg grunderna för utvecklarens självbetjäning:

Som bilden visar utgör följande komponenter kärnan i begreppet självbetjäningsgrund för utvecklare:

Komponent	Description
API för utvecklarplattform	Din enda kontaktpunkt för användarupplevelser. Det är i praktiken systemets kontrakt med andra system.
Plattformsdiagram för utvecklare	Ett hanterat och säkert datadiagram som gör att du kan identifiera, associera och använda olika typer av entiteter och mallar. En entitet är ett objekt som möjliggör dataaggregering från flera källor, medan mallar styr användarindata som möjliggör automatisering.
Plattformsorkestrerare för utvecklare	En funktion som dirigerar och spårar mallbaserade begäranden för att utföra åtgärder antingen i ett system eller via en manuell process. Dessa begäranden dirigeras till en av en uppsättning leverantörer av utvecklarplattformar som kan integreras i valfritt antal olika arbetsflödessystem eller andra tjänster.
Leverantörer av utvecklarplattform	En uppsättning komponenter som kapslar in logik som behövs för att integrera med underordnade system för att stödja CRUD-åtgärder på entiteter eller uppfyllande av mallbaserade åtgärdsbegäranden. Varje leverantör kan stödja sin egen specifika typ av mallar och generera antingen unika eller vanliga typer av entiteter.
Användarprofil och teammetadata	En funktion för att bevara information om en uppsättning individer som är knutna till ett konceptuellt team för gruppering och åtkomst till utvecklarplattforms-API:et. Användaren är nära associerad med ett identitetsproviderkonto (till exempel Inloggning med Microsoft Entra-ID), men både det och ett team kan koppla till valfritt antal relaterade underordnade systemrepresentationer. En implementering av det här informationsarkivet är att återanvända plattformsgrafen för utvecklare. Utvecklarens självbetjäningsgrund kan upprätta en gemensam entitetstyp för både en användare och ett team och bevara den informationen i diagrammet. Men vi kommer att hålla den här butiken separat för tydlighetens skull.

Med dessa grundläggande komponenter kan du använda och byta ut olika byggstenar över tid.

Måste jag bygga allt detta för att komma igång?

Nej. För det första är detta en konceptmodell som hjälper dig att tänka igenom vad en grund som denna ska kunna göra när den är klar. För det andra är implementeringsspecifika detaljerna mindre viktiga här med tanke på att utvecklarplattforms-API:et blir ditt nyckelgränssnitt. Den inledande implementeringen kan börja med att använda gränssnitt och klasser i koden för de olika lager som beskrivs eller med att integrera andra produkter. Du kan också utelämna aspekter eftersom din kundutveckling säger att det helt enkelt är en lägre prioritet. Börja med det du har och växa.

API för utvecklarplattform

Du bör definiera ett utvecklarplattforms-API som fungerar som systemets kontrakt. API:et används av olika användargränssnitt för att aktivera dataåtkomst eller enhetsetablering och andra åtgärder.

Det här API:et fungerar som ett viktigt autentiserings- och säkerhetslager genom att begränsa åtkomsten till råa underliggande API:er i andra system till mer specifika, kontrollerade data och åtgärder. API:et ger åtkomst till sin egen representation av en användarprofil, en användares övergripande roll inom plattformen (teammedlem, administratör osv.) och systemidentifierare för primär identitetsprovider. Mer information finns i Användare och team.

Leverantörer av utvecklarplattform

Med tanke på bredden i en intern utvecklarplattform bör du skapa eller identifiera system som följer en utökningsbar providermodell för att introducera funktioner i API:et. Tanken är att viktiga funktioner som automatisering och dataaggregering tillhandahålls genom interaktion med pluggbara komponenter med väldefinierade gränssnitt. Den här lösa kopplingen hjälper dig att tråda in det du behöver stegvis och förbättrar underhållsbarheten eftersom du kan testa funktioner oberoende av resten av grunden.

Det är också ett viktigt sätt att aktivera en skalbar inre källmentalitet för din plattform. Vanligtvis lyckas insatser för innersourcing inom plattformsteknik sällan att få genomslag på grund av utmaningar med fortlöpande underhåll. Andra team kan vara villiga att bidra med funktioner men är mindre benägna att vara villiga att underhålla och testa något i kärnan av din plattform. Omvänt har alla centraliserade team begränsad kapacitet för att underhålla kod som har bidragits med eller till och med granska pull requests. Konceptet med en leverantör av utvecklarplattform minskar spänningen genom att tillåta fristående skriven kod att ansluta till kärnfunktioner i utvecklarens självbetjäningsgrund. Även om du noggrant bör hantera vilka leverantörer du använder, granska all providerkod och begränsa den yta som en viss leverantör kan komma åt i din utvecklarplattform, kan en anslutningsbar metod hjälpa dig att få mer gjort genom att skala arbetet i en bredare del av organisationen.

Viktiga begrepp för plattformsleverantörer för utvecklare

Entities

Begreppet en entitet är något som en utvecklare eller ett annat system i din interna utvecklarplattform behöver spåra, uppdatera, presentera eller agera på. Entiteter kan ha relationer med varandra som när de tas tillsammans utgör ett diagram som ger viktig information om delar av din interna utvecklarplattform. Utvecklarplattformsleverantörer kan sedan mata ut entiteter för att aktivera kärnfunktioner, inklusive:

• Surfa på externt etablerade resurser/miljöer eller tillgängliga API:er för identifiering och användning
• Exponera relationer för beroendeanalys, påverkansanalys, identifiering osv.
• Uppslagsunderhållare/ägarskapsinformation för identifiering och samarbete
• Att göra mer data tillgänglig för användning i användarupplevelser.

Att kapsla in den här funktionen i ett väldefinierat leverantörsgränssnitt för utvecklarplattform förenklar integrering och testning, möjliggör oberoende distribution och gör det möjligt för utvecklare utanför det primära interna utvecklarplattformsteamet att bidra och hantera leverantörer. Detta är viktigt i stora organisationer eller divisioner där inte alla verktyg, tjänster eller plattformar hanteras centralt, men den bredare organisationen vill fortfarande dela funktioner. Så även om du inte går den här vägen från början är det något att tänka på på lång sikt.

Gemensamma egenskaper

Varje entitet bör ha en uppsättning gemensamma egenskaper som gör att grunden kan hantera dem. Några egenskaper att tänka på är:

• Unik identifierare
• Namn
• Ursprungsprovider
• Valfria associationer för att:
  • Ägaranvändare
  • Ägarteam
  • Andra enheter

Användar- och teamegenskaperna är viktiga av tre skäl: rollbaserad åtkomstkontroll (RBAC), identifiering och dataaggregering (till exempel sammanfattningar på teamnivå). Att införliva RBAC från början är viktigt för säkerheten och att din interna utvecklarplattform växer över tid. Med tanke på att utvecklingen är en lagsport blir det snabbt viktigt att upptäcka vem man ska prata med om en enhet för återanvändning, support och innersourcing.

Vanliga och providerspecifika entiteter

Du bör också kunna upprätta en uppsättning vanliga, normaliserade entiteter på hög nivå som flera leverantörer kan mata ut. Till exempel:

• Environments
• Resurser
• API:er
• Arkiv
• Components
• Tools

Dessa bör vanligtvis vara på en hög nivå, som du skulle placera i C4-modellkontexten eller på de flesta högnivåkomponentdiagram. För en miljö behöver du till exempel inte ta med information om den interna infrastrukturtopografin. du behöver bara tillräckligt med information för att lista och associera olika konceptuella miljöer från flera leverantörer i samma UX. Entiteten kan peka på lägre detaljnivåer utanför själva systemet i stället för att försöka konsumera allt. Dessa ger startpunkter för identifiering som är centrala för att aktivera dataaggregering över tid.

Andra är specifika för ett visst användningsfall eller en viss leverantör, så du bör tänka på hur du kan hantera en växande uppsättning entitetstyper över tid.

Mallar

Begreppet mall i den här kontexten skiljer sig från idén om entiteter eftersom de är avsedda att köra en åtgärd. Exempelscenarier är infrastrukturetablering, skapande av en lagringsplats och andra tidskrävande processer. Dessa mallar bör också vara tillgängliga via utökningsbara utvecklare plattformsleverantörer och bör stödja samma gemensamma egenskaper som entiteter, inklusive entitetsassociationer.

De kan dock också definiera nödvändiga indata, oavsett om systemet eller användaren har angetts, som behövs för att utföra åtgärden. Dessa kan vara allt från att namnge resursen till valfria tillägg.

Exempel på mallar är:

• IaC-mallar (Infrastruktur som kod)
• Programmallar (start höger) eller malllagringsplatser
• Skapa pipeline/arbetsflödesmallar
• Distributionspipeline/arbetsflödesmallar
• Parametriserade skript
• Parameteriserade Power Automate-flöden (till exempel ett HTTP-begäran-utlöst molnflöde)
• E-postmallar

Precis som entiteter kan mallar innehålla providerspecifika egenskaper.

Varje mall kan ha en annan representation som är unik för providern. Dessa kan vara allt från Terraform- eller ARM-mallar till Helm-diagram, parameteriserade GitHub Actions-arbetsflöden eller Azure Pipelines, enkla skript eller anpassade format.

Den faktiska underliggande mallinformationen behöver inte nödvändigtvis lagras centralt. De kan finnas i olika lagringsplatser, register eller kataloger. Du kan till exempel använda GitHub-malllagringsplatser för dina programmallar, medan dina IaC-mallar kan finnas på en begränsad kataloglagringsplats som utvecklare bara indirekt kan komma åt via något som liknar Azure Deployment Environments. Andra IaC-mallar kan lagras i ett OCI Artifact Registry som Helm-diagram. I andra fall kan mallen vara en referens till en parameteriserad HTTP-slutpunkt. En leverantör av utvecklarplattformen bör tillhandahålla tillräckligt med information om varje typ av mall så att de kan refereras till och alla alternativ som exponeras för användning i användarupplevelser. Men själva mallarna kan vara inrymda på den mest naturliga platsen för dina användningsfall.

Plattformstekniker eller experter på ett visst område skriver mallar och delar dem sedan med utvecklingsteam för återanvändning. Genom att centralisera användningen av dessa mallar via ett system kan utvecklare använda självbetjäning och inrätta riktlinjer som hjälper till att upprätthålla efterlevnaden av organisationens standarder eller riktlinjer. Mer om detta när vi diskuterar orkestratorn för utvecklarplattformen snart.

Plattformsdiagram för utvecklare

Du kan se ett plattformsdiagram för utvecklare som något som gör att du kan associera entiteter och mallar från flera leverantörer till ett sökbart diagram. Faktiska data för entiteterna behöver dock inte nödvändigtvis sparas direkt i en grafspecifik databas. I stället kan interaktioner med leverantörer cachelagras tillsammans med nödvändiga metadata för att få allt att passa ihop.

Diagrammet är kraftfullt när det används med vanliga entiteter som flera leverantörer kan bidra med. En lista över API:er kan till exempel komma från en produkt som Azure API Center, men du kanske också vill mata in distributioner och miljöer automatiskt från dina system för kontinuerlig distribution. Med tiden kan du växla mellan olika distributionssystem eller till och med stödja mer än ett distributionssystem. Så länge varje distributionssystem har en plattformsleverantör för utvecklare bör du fortfarande kunna skapa associationen.

Var och en av dina användarupplevelser som byggs upp från det här diagrammet kan sedan dra nytta av ett gemensamt API för att skapa identifiering, sökning, styrning med mera. En plattformsorkestrerare för utvecklare kan sedan dra nytta av samma diagram så att alla åtgärder som utförs av en leverantör av utvecklarplattform automatiskt bidrar med entiteter som är tillgängliga för samma API.

Plattformsorkestrerare för utvecklare

Med en plattformsorkestrerare för utvecklare kan utvecklare eller system skapa begäranden för att utföra en åtgärd med hjälp av en mall. Den utför inte själva åtgärderna, utan samordnar i stället med en aktivitetsmotor, arbetsflödesmotor eller en annan orkestrerare för att göra det. Det är en av de viktigaste delarna som du bör försäkra dig om att den ingår i din självbetjäningsplattform. Det gör att utvecklare kan skapa begäranden med en mall eller köra en åtgärd utan direkt behörighet. Till skillnad från begreppet CI eller CD behöver dessa åtgärder inte heller vara relaterade till programmets källkod.

Du kan använda GitHub Actions, Azure Pipelines eller en annan arbetsflödesmotor som orkestrerare. Det här är en rimlig plats att börja på, men du kanske vill ha lite abstraktion på plats så att olika typer av mallar kan använda olika underliggande motorer. Detta kan vara användbart av några anledningar:

• Först vill du förmodligen kunna välja olika arbetsflödes- och aktivitetskörningsmotorer över tid utan att behöva flash cut. Genom att tillåta fler än en motor kan du migrera över tid eller helt enkelt använda den nya motorn till nya åtgärder utan att påverka äldre.
• Vissa processer som du vill samordna kan kräva manuella steg från början även om du planerar att automatisera dem helt senare.
• Andra åtgärder kan rikta in sig på roller utanför utvecklingsteamet, till exempel leverantörsreskontra eller en licensadministratör. Lågkodsmotorer som Power Automate fungerar ofta bra för dessa roller.
• Andra åtgärder kan hanteras via enkla HTTP-begäranden där det inte är nödvändigt eller kostnadseffektivt att skapa något så kapabelt som GitHub Actions eller Azure Pipelines .

Lyckligtvis kan en utökad roll för en plattformsleverantör för utvecklare, att täcka automatiseringssteg för att utlösa och spåra, ge denna nödvändiga abstraktion. Tänk på följande bild:

Här är det allmänna konceptet:

• Mallar kan också ange en uppsättning indata som användaren kan ange. När en utvecklare utlöser en viss åtgärd väljer de en mall (även om den inte beskrivs på det sättet) och anger eventuella indata.
• En referens till mallrelaterade indata blir en begäran i API:et för utvecklarplattformen.
• När en begäran har skickats börjar en komponent för routning och hantering av begäran i orkestreraren spåra livscykeln för begäran. Begärans routnings- och hanteringskomponent dirigerar mallen i begäran till den utvecklarplattformleverantör där mallen har sitt ursprung.
• Utvecklarplattformsprovidern utför sedan lämpliga steg för implementeringen.
• (Valfritt) Utvecklarplattformsprovidern uppdaterar statusen för begäran när den utför åtgärden.
• När begäran har uppfyllts kan utvecklarplattformsprovidern returnera en uppsättning entiteter för att lägga till eller uppdatera i utvecklarplattformsgrafen. Dessa kan vara providerspecifika eller vanliga entiteter.

Om du vill ha stöd för mer avancerade interaktioner kan leverantörer av utvecklarplattform anropa utvecklarplattforms-API:et direkt för att antingen få fler entiteter som indata eller till och med begära en annan relaterad åtgärd.

Välj en plattformsleverantör för utvecklare som använder en allmän uppgifts- eller arbetsflödesmotor. Mer specifikt vill du ha något som överbryggar det du sätter ihop som en del av Tillämpa programvarutekniksystem. En allmän arbetsflödes- eller uppgiftskörningsmotor att investera i är ett CI/CD-system.

Ett exempel med GitHub Actions eller Azure Pipelines

Låt oss kort titta på hur en GitHub Actions eller Azure Pipelines som leverantör av utvecklarplattform skulle fungera.

För GitHub Actions är nyckeln till att göra det här arbetet att en leverantör av utvecklarplattform kan ansluta till den angivna GitHub-instansen och använda REST API:et Actions för att utlösa en arbetsflödessändningshändelse för att utlösa en arbetsflödeskörning. Varje arbetsflöde kan stödja en uppsättning indata genom att lägga till en workflow_dispatch konfiguration i YAML-filen för arbetsflödet. Azure DevOps-utlösare liknar dem och du kan också använda Azure DevOps Pipeline API för körningar. Du kommer förmodligen att se samma funktioner i andra produkter.

Dessa arbetsflöden eller pipelines behöver inte finnas i programkällans lagringsplatser. Konceptet skulle vara att dra nytta av detta faktum för att göra något som liknar detta:

• Plattformstekniker eller DevOps-teammedlemmar kan underhålla arbetsflöden/pipelines på en eller flera centrala lagringsplatser som utvecklare själva inte har åtkomst till, men utvecklarplattformsleverantören är konfigurerad att använda. Samma lagringsplats kan innehålla skript och IaC-kodfragment som arbetsflöden/pipelines använder.
• Om du vill tillåta dessa arbetsflöden/pipelines att interagera med lämpligt system nedströms kan ops eller andra medlemmar i ditt plattformsteknikteam lägga till nödvändig säkerhetsinformation i det centrala repositoriet. Mer information om hur du gör detta finns i GitHub Actions och Azure DevOps-dokumentationen , eller så kan du välja att centralisera hemligheterna med något som liknar Azure Key Vault.
• Dessa arbetsflöden/pipelines kan sedan följa en modell där de publicerar resulterande entiteter som en kompilerings-/distributionsartefakt (GitHub-dokument, Azure DevOps-dokument).
• Under en körning kan utvecklarplattformsprovidern sedan titta på tillståndet för arbetsflödet/pipelinen och uppdatera livscykelstatusen i orchestrator tills den är klar. Du kan till exempel använda webbkrokar med GitHub Actions och tjänstkrokar med Azure Pipelines för att spåra uppdateringar.
• När det är klart kan providern sedan använda den publicerade artefakten för att inkluderas i utvecklarplattformsdiagrammet efter behov.

Slutligen kan du konfigurera den här utvecklarplattformsprovidern för att mata ut en uppsättning mallar till plattformsgrafen för utvecklare som refererar till lämplig lagringsplats och arbetsflöde/pipeline, tillsammans med indata för en viss uppgift.

Det som är bra med att använda ett CI/CD-system är att de ofta har konfigurerats för att stödja körning av godtyckliga CLIs, så du behöver ingen unik integrering i första klass för allt du gör. Du kan lägga till dem över tid efter behov.

Mycket av det som beskrivs i det här exemplet gäller för hur andra typer av leverantörer kan fungera. Det är också viktigt att observera att användningen av GitHub Actions eller Azure Pipelines i den här kontexten inte kräver att du även använder dem för dina faktiska CI/CD-pipelines.

Andra exempel

Här följer några exempel på andra typer av utvecklare som kan bearbeta mallar.

Example	Description
Åtgärder för källkontroll	I vissa fall kan du behöva skapa eller uppdatera en lagringsplats, skicka en pr eller utföra en annan källkontrollrelaterad åtgärd. Även om allmänna asynkrona arbetsflödesmotorer kan hantera den här typen av åtgärder kan det vara användbart att kunna utföra grundläggande Git-åtgärder utan någon.
Infrastrukturleverantörer	Även om GitHub Actions och Azure Pipelines fungerar bra för att hantera infrastrukturetablering kan du även välja fler direkta integreringar. En dedikerad provider kan effektivisera konfigurationen och undvika omkostnader. Tjänster som Azure Deployment Environments eller Terraform Cloud fokuserar mer direkt på att aktivera IaC-mallbaserad etablering och på ett säkert och säkert sätt. Andra exempel kan vara saker som att skapa Kubernetes-namnområden för program i delade kluster eller använda Git med GitOps-arbetsflöden med Flux eller Argo CD som en specifik typ av provider. Ännu fler appcentrerade modeller som det experimentella Radius OSS-inkubationsprojektet med egna CLI:er kan ha sina egna utvecklares plattformsleverantörer över tid. Det viktigaste är att leta efter och planera för utökningsbarhet så att du kan anpassa dig.
Applikationsställning/initiering	Programmallar är en viktig del av var plattformsutveckling leder över tid. Du kan stödja valfri mallmotor genom att tillhandahålla en dedikerad plattformsleverantör för utvecklare som är utformad för att inte bara skapa ett programkällträd, utan även skapa och push-överföra innehåll till en källkodslagringsplats och lägga till de resulterande entiteterna i grafen. Varje ekosystem har sina egna inställningar för applikationsställning, oavsett om det är Yeoman, cookiecutter eller något som liknar Azure Developer CLI, så kan providermodellen här ge dig stöd för mer än en från samma gränssnitt. Här är det återigen utökningsbarheten som är nyckeln.
Manuella processer	Oavsett om du automatiskt genererar en PR för manuellt godkännande eller manuella arbetsflödessteg för icke-utvecklarpersoner att svara på med något som liknar Power Platform kan samma mallbaserade modell användas i en utvecklarplattformleverantör. Du kan till och med gå över till mer automatiserade steg över tid.

Även om du kanske inte behöver alla dessa leverantörer för att starta, kan du se hur utökningsbarhet genom något som liknar en leverantör av utvecklarplattform kan hjälpa dina automatiseringsfunktioner att växa med tiden.

Användare och team

Plattformsteknik är till sin natur en affär med flera system, så det är viktigt att planera hur en självbetjäningsgrund ska hantera de mer utmanande problemen med att integrera dessa system tillsammans. Här är en strategi för att hantera vanliga utmaningar med identitet, användare och team.

Recommendation	Description
Integrera utvecklarplattforms-API:et direkt med din identitetsprovider för optimal säkerhet.	För att skydda utvecklarplattforms-API:et rekommenderar vi direkt integrering med en identitetsprovider som Microsoft Entra ID, med tanke på dess robusta identitet och Entra ID:s RBAC-funktioner. Det finns många fördelar med att direkt använda en identitetsproviders interna SDK:er och API:er (till exempel via MSAL Entra-ID) i stället för genom en abstraktion. Du kan skapa säkerhet från slutpunkt till slutpunkt och förlita dig på samma RBAC-modell hela tiden samtidigt som du säkerställer att principer för villkorlig åtkomst kontinuerligt utvärderas (till skillnad från endast vid tidpunkten för inloggningen).
Använd gruppintegreringar för enkel inloggning och identitetsprovider i underordnade system.	Dina integreringar med enkel inloggning (SSO) bör använda samma identitetsprovider och klientorganisation som du använder för utvecklarplattformens API. Se också till att dra nytta av stöd för protokoll som SCIM för att koppla in identitetsprovidergrupper (till exempel AD-grupper). Att koppla dessa identitetsprovidergrupper till underordnade systembehörigheter är inte alltid automatiskt, men du kan åtminstone manuellt associera leverantörsgrupper med varje verktygs grupperingsbegrepp utan att manuellt hantera medlemskap efteråt. Du kan till exempel kombinera GitHubs stöd för Enterprise Managed User (EMU) tillsammans med att manuellt dra nytta av möjligheten att koppla identitetsprovidergrupper till GitHub-team. Azure DevOps har liknande funktioner.

Etablera konceptet för ett team utöver en enda identitetsprovidergrupp

När din plattformsutveckling fortsätter kommer du förmodligen att märka att identitetsprovidergrupper är bra för att hantera medlemskap, men att flera grupper verkligen måste samlas för att bilda konceptet med ett team för RBAC och dataaggregering.

Inom ramen för plattformsteknik definierar vi ett team som en uppsättning personer i olika roller som arbetar tillsammans. Vid dataaggregering är idén om ett team med flera roller avgörande för att möjliggöra upptäckten och sammanställningen av information på platser som rapporteringsinstrumentpaneler. Å andra sidan är en grupp ett allmänt identitetsproviderkoncept för en uppsättning användare och är utformad med idén att lägga till flera personer till en specifik roll, snarare än tvärtom. Med RBAC kan ett team därför relatera till flera identitetsprovidergrupper via olika roller.

Källan till dina teamdata kan komma från några olika platser. Om du till exempel använder mönstret teams as code (TAC) kan en leverantör av utvecklarplattform titta efter filändringar på en lagringsplats och cachelagrar dem i en användarprofil och ett teammetadatalager. Eller så kan du integrera direkt med något som liknar ett Azure Dev Center-projekt som redan har dessa grundläggande RBAC-konstruktioner tillgängliga.

Upprätta en modell för integrering med underordnade system på team- eller användarnivå

Vissa utvecklar- och driftsverktyg/-tjänster integrerar och använder begrepp som identitetsprovider direkt, men många abstraherar detta i sin egen representation av en grupp eller användare (även med enkel inloggning). Förutom att aktivera åtkomst mellan verktyg kan den här verkligheten också innebära problem för dataaggregering. Mer specifikt kan du upptäcka att API:er i underordnade system använder sina egna identifierare i stället för identitetsprovideridentifierare (till exempel används inte objekt-ID i Entra-ID direkt). Det gör det svårt att filtrera och associera data på användar- eller teamnivå om du inte kan mappa mellan olika ID:n.

Adressera skillnader på team- och gruppnivå

Med mönster som TaC kan du lagra och komma åt relationer mellan varje systems team- eller gruppidentifierare så att du kan mappa mellan dem. För att sammanfatta blir en säker, granskningsbar Git-lagringsplats källan till ett team, och PR:er tillhandahåller ett kontrollerat användargränssnitt för att göra uppdateringar. CI/CD-system kan sedan uppdatera underordnade system och bevara relaterade identifierarrelationer för det team som det använde för att göra det.

Detta gör till exempel att följande relationer kan lagras för i API-anrop:

Om du föredrar att använda en annan datakälla än filer i en lagringsplats som dina team använder kan samma allmänna begrepp användas med utvecklarplattformsorkestreraren för att åstadkomma samma sak. Enligt den här modellen kan en leverantör av utvecklarplattform för källan till teamdata utlösa en teamuppdateringshändelse som alla andra leverantörer tar emot och agerar på efter behov.

Hantera användar-ID-utmaningar

En annan relaterad utmaning för dataåtkomst och aggregering är skillnader i användar-ID. Precis som i teamfallet kan du inte anta att identitetsprovidrars interna ID (till exempel objekt-ID för Entra-ID) stöder ett visst API om du använder en system-till-system-integrering för att fråga efter data om en användare. Här kan det vara till hjälp att lagra en mappning för ett användar-ID som kommer åt data via utvecklarplattforms-API:et. Överväg till exempel GitHub:

Om du för varje system kan göra en sökning av ett användar-ID i ett annat system via ett API utan en användartoken, kan en viss leverantör av utvecklarplattform generera den här mappningen direkt. I vissa fall kan detta bli komplicerat eftersom du kan behöva utföra den här åtgärden i bulk och cachelagra resultaten för att kunna underhålla prestanda.

Återgå till att använda flera användartoken

För situationer där leverantörer behöver komma åt data på användarnivå utan ett sätt att göra översättning av användar-ID som skulle fungera kan utvecklarplattforms-API:et konfigureras för att hantera flera användartoken. Till exempel:

• Utvecklarplattformens API kan stödja en cache med leverantörsspecifika användartoken för användning i efterföljande system.
• Eventuella interaktioner med en viss provider som utlöses av API:et skulle inkluderas i providerns användartoken om det är tillgängligt.
• För att hantera det fall där ingen användartoken var tillgänglig skulle providern utlösa ett OAuth-flöde för att hämta en.
• Till att börja med skickar utvecklarplattforms-API:et tillbaka en autentiserings-URI för ett OAuth-flöde med en omdirigerings-URI som skickades till providern. Den URI som skickades in skulle innehålla en nonce-/engångskod.
• API:et returnerar sedan ett inte autentiserat svar med URI:n.
• Valfritt UX kan sedan använda den här URI:n för att driva rätt autentiseringsflöde i en webbläsare.
• När omdirigeringen sker får utvecklarplattformen den nödvändiga användartoken och cachelagrar den för framtida referens tillsammans med användar-ID:t.
• Klienten kan sedan försöka med API-anropet igen, vilket sedan skulle lyckas.

Det här konceptet beskriver ett sätt att hantera komplicerad autentisering eftersom du kan återanvända ID:er där det är möjligt och inte behöver underhålla separata omdirigerings-URI:er per nedströmssystem.

Använda sammanhangsmedvetna djuplänkar till verktyg och rapporteringssystem

Hittills har vi pratat om automatiseringsaspekten av problemutrymmet. Det här kan gå långt eftersom användargränssnittet kan använda värden i de entiteter som returneras under automatiseringen för att skapa djupa länkar till andra system för teamet.

Även om det inte är automationsrelaterat kan utvecklares plattformsleverantörer generera alla typer av entiteter som behövs. Men i allmänhet vill du inte ta med alla detaljerade data i hela din interna utvecklarplattform till ditt plattformsdiagram för utvecklare. Instrumentpaneler i observerbarhetslösningar som Grafana, Prometheus, DataDog eller kodinformation i produkter som SonarQube och inbyggda funktioner i DevOps-sviter som GitHub och Azure DevOps är alla kompatibla. I stället är den bästa metoden ofta att skapa djupa länkar till dessa andra system. Dina entiteter kan tillhandahålla tillräckligt med information för att skapa länkar utan att direkt innehålla detaljerad information som logginnehåll.

För fall där du vill ha aggregerade och sammanfattade data mellan verktyg eller behöver köra anpassade mått kan rapporteringslösningar i Power BI eller Microsoft Fabric vara nästa anropsport. Om du vill sammanfoga teamdata kan du antingen ansluta till din foundations databas eller gå igenom ett API för utvecklarplattform. Till exempel, som beskrivs i Planera och prioritera, kan ett område där du kan behöva en anpassad instrumentpanel vara att mäta framgången för din interna utvecklarplattform.

Var selektiv med varje extra upplevelse du skapar

Det kan vara tilltalande att återskapa befintliga funktioner i något som liknar en gemensam portal, men kom ihåg att du också måste underhålla den. Detta är det område där det är viktigt att följa ett produkttänk. Gränssnitt i instrumentpanelsstil är enkla att tänka ut och förstå, men utvecklarna kanske hittar mer värde någon annanstans.

Med den här modellen kan du använda aggregerade data i utvecklarplattformsgrafen för att skapa anpassade användarupplevelser. Entiteter bör ha inbyggt stöd så att de kan kopplas till en användare eller ett team. På så sätt kan API:et för utvecklarplattformen begränsa utdata (tillsammans med indexering och cachelagring).

Men även om du behöver skapa anpassad UX i stället för en djuplänk är det vanligtvis inte den bästa metoden att hämta alla data till grafen för utvecklarplattformen. Tänk dig till exempel en situation där du kanske vill visa loggar i ditt användargränssnitt som redan har en väldefinierad och hanterad startsida. Använd information i relaterade entiteter för att hjälpa ditt användargränssnitt att samla in information direkt från underordnade system.

För att starta kan du behöva använda en system-till-system-integrering för att ansluta, men när du har implementerat en av modellerna som beskrivs i användare och team kan du använda alla lagrade underordnade användar-/team-ID:er eller användarautentiseringstoken om det behövs.

Här är några exempel på vanliga upplevelser att tänka på:

Example	Description
Identifiering och utforskning	Som en plattformstekniker uttryckte det: "Det som saktar ner projekt är kommunikation, inte utvecklarkunskaper." – Daniel, molntekniker, Fortune 500 Media Company. Eftersom programvara är en lagsport är det vanligtvis en av de första sakerna att ta itu med att skapa ett användargränssnitt för att identifiera team och de entiteter som de äger. Sökning, upptäckt och dokumentation mellan team främjar återanvändning och underlättar samarbete för inre källkodsprojekt eller supportsyften. Teams har också nytta av att ha en enda kontaktpunkt för att hitta saker som de äger, inklusive miljöer, lagringsplatser och andra resurser som dokument.
Manuell registrering av miljöer eller resurser	Många saker kan etableras och spåras via utvecklarplattformsorkestratorn, men du kanske också vill registrera resurser eller miljöer som redan finns eller inte är automatiserade ännu. En enkel provider som tar information från en git-lagringsplats och lägger till information i resurser/miljöhantering kan vara användbar här. Om du redan har en programvarukatalog blir det också ett sätt att integrera den i modellen.
Ett API-katalog	Spårning av API:er som utvecklare bör använda kan gå långt. Om du inte redan har något kan du till och med börja med en enkel Git-lagringsplats med en serie filer som representerar API:er, deras status, med hjälp av PR:er för att hantera arbetsflödet för godkännande. Dessa kan läggas till i ditt plattformsdiagram för utvecklare så att de kan visas eller associeras med andra entiteter. Om du vill ha mer robusta funktioner kan du integrera något som Microsofts API Center eller någon annan produkt.
Licensefterlevnad	I vissa fall kanske du också vill ge insyn i programvarulicensefterlevnad och licensförbrukning. Utvecklarplattformar kan också lägga till den automatisering som krävs för att använda licenser, men även om licenser tilldelas manuellt (till exempel via en PR-process i en Git-lagringsplats) kan utvecklaren se vad de har (och administratörens möjlighet att se över allt).
En programcentrerad vy över Kubernetes	När du använder ett delat Kubernetes-kluster kan det vara svårt för utvecklare att hitta och förstå tillståndet för sina program via klusteradministratörs-UX. Olika organisationer kan välja att hantera det här problemet på ett annat sätt, men att använda ett namnområde för att representera ett program är ett välkänt sätt att göra det på. Därifrån kan du använda entiteter för att upprätta associationer mellan programmets namnområde i klustret och ett team och skapa en mer utvecklarfokuserad vy över status för programmet och tillhandahålla djupa länkar till andra verktyg eller webb-UIs.

Användarupplevelser

Olika roller i din organisation har verktyg eller tjänster som representerar en tyngdpunkt för deras dagliga arbete. Dragningskraften hos dessa system kan göra det svårt för nya användarupplevelser utanför dessa tyngdpunktsområden att få fotfäste. I en perfekt värld kan utvecklare, åtgärder och andra roller fortsätta att fungera i en miljö som passar dem, ofta de som de redan använder.

Med detta i åtanke är det en bra idé att planera för flera användargränssnitt när du går vidare med din plattformsteknikresa. Detta kan också ge en möjlighet att börja enkelt, bevisa värde och växa mot mer komplexa gränssnitt när behovet uppstår.

Integrera det du har

Om du har läst igenom artiklarna Tillämpa programvarutekniksystem och Förfina programplattform har du förmodligen identifierat de system som du vill fortsätta att använda. I båda fallen ska du utvärdera om du kan förbättra och utöka det du har innan du börjar skapa nya upplevelser från grunden. (Fråga dig själv, kommer människor att reagera bättre på en annan ny användarupplevelse eller en förbättrad version av något de har nu?)

Vissa av de verktyg, verktyg eller webbappar som du vill fortsätta använda kommer att vara anpassade, och dessa är bra kandidater för förbättringar. Men glöm inte att vara uppmärksam på om dina favoritverktyg och tjänster har en utökningsmodell som du kan använda. Du kommer att få mycket nytta av att börja där. Detta kan eliminera underhåll och säkerhetsproblem och gör att du kan fokusera på det problem som du försöker lösa

Du kanske till exempel kan utöka följande ytor som du redan använder:

• Redigerare och IDE:er
• Din DevOps-svit
• ÄVEN CLI:er blir alltmer utökningsbara
• Miljöer med låg/ingen kod, till exempel Power Pages

Var och en kan vara en bättre utgångspunkt för en viss roll än något du har konfigurerat från grunden eftersom de är befintliga tyngdpunkter. Med ett gemensamt API för utvecklarplattform som baslinje kan du växla ut saker, experimentera och ändra över tid.

Överväg webbredigerarens tillägg för att skapa en utvecklarportal

Om du letar efter en webbaserad upplevelse för utvecklare bör du tänka på att en ny trend är webbaserade versioner av redigerare och IDE:er. Många, som de som använder VS Code, har tilläggsstöd. Med VS Code översätts allt du skapar för dessa webbupplevelser lokalt för en dubbel fördel.

Förutom tjänster som GitHub Codespaces är vscode.dev en kostnadsfri webbversion av VS Code-redigeraren utan beräkning, men har stöd för vissa typer av tillägg , inklusive de som använder webbvyer för anpassat användargränssnitt.

Även om utvecklarna inte använder själva VS Code är UX-mönstren välkända och finns i andra utvecklarverktyg. Att använda vscode.dev kan ge en praktisk och välbekant webbaserad grund för utvecklarupplevelser utöver själva verktyget.

Dessa kan fungera som en utvecklarfokuserad portal i ett välbekant format som också kan översättas till lokal användning.

ChatOps

En annan möjlighet som ofta förbises är att implementera ett ChatOps-gränssnitt. Med tanke på ökningen av chattbaserade gränssnitt på grund av ökningen av AI-produkter som ChatGPT och GitHub Copilot kan åtgärdskommandon eller snedstreckskommandon vara ett användbart sätt att utlösa automatiseringsarbetsflöden, kontrollera status med mera. Eftersom de flesta CI/CD-plattformar för program har stöd för system som Microsoft Teams, Slack eller Discord kan detta vara ett naturligt sätt att integrera med andra utvecklare av användargränssnittet och relaterade driftroller som används varje dag. Dessutom har alla dessa produkter en utökningsmodell.

Investera i en ny utvecklarportal

Förutsatt att du inte har någon befintlig portal eller ett befintligt gränssnitt som du vill använda som bas kan du välja att skapa en ny utvecklarportal. Tänk på detta som ett mål i stället för en startpunkt. Om du inte redan har ett utvecklingsteam som arbetar med dig är det dags att starta den här ansträngningen. Varje organisation är annorlunda, så det finns inget svar som passar alla för vad som ska finnas i den här typen av upplevelse. Därför finns det inget standardsvar för en färdigförpackad produkt som du kan starta och använda som den är för något liknande idag.

För anpassade självhanterade alternativ är allmänna webbportalramverk inte nya och utvecklingsteamen kanske redan använder ett som du kan utnyttja. Om du försöker få ut något framför dina användare för tidig feedback kan du till och med börja med något så enkelt som power pages med låg kod för att ansluta till ett gemensamt utvecklarplattforms-API.

De senaste utvecklarportalinsatserna är mer utlåtande. Till exempel är Backstage.io ett anpassat verktyg för utvecklarportalen som ursprungligen skapades för att uppfylla Spotifys behov. Den innehåller ett CLI som hjälper dig att starta källträdet ungefär som create-react-app gör för React.js.

Som en portalverktygsuppsättning kräver det arbete för att komma igång och anpassning kräver kunskaper om TypeScript, Node.jsoch React. Men det fantastiska med det är att verktygslådan gör att du kan ändra nästan vad som helst. Den har också en egen programvarukatalog och en mallmekanism, men deras användning krävs inte, och det är ett väldefinierat sätt att ta in ny kod som kallas plugin-program.

Relaterat innehåll

• Microsoft Power Pages
• Backstage.io
• Tillämpa programvarutekniksystem