Utforma en självbetjäningsgrund för utvecklare

När du har god förståelse för ditt mål för dina tekniska system kan du börja skapa mer avancerade självbetjäningsupplevelser för utvecklare. I det här avsnittet beskriver vi en konceptuell arkitektur för att skapa eller utvärdera produkter som skapar en flexibel grund för att skapa dem. Vi refererar till dessa begrepp, mönster och komponenter tillsammans som en självbetjäningsgrund för utvecklare.

Ä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. I din värld kan den här modellen 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 i det här avsnittet, men modellen kan fortfarande hjälpa dig att orientera dig.

Goals och överväganden

Huvudmålet för ditt arbete i det här området bör vara att aktivera självbetjäning med skyddsräcken genom kontrollerad, styrd aktivitetskörning och etablering, tillsammans med centraliserad synlighet. De områden som ofta ä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 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 supportprocess.

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

Svårigheterna omfattar 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-tekniker, stort logistikföretag

Som det här citatet belyser är det vanligtvis inte möjligt att snabbt byta till en ny eller uppdaterad standard, 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, när dina självbetjäningsbehov växer, är variabilitet oundviklig. Därför vill du aktivera kontrollerade experiment där utsedda team kan prova nya tekniker, distributionsstrategier och så vidare, följt av avsiktligt införande och en inkrementell distribution.

I allmänhet finns självbetjäningsupplevelser i två primära kategorier:

• Automation
• Dataaggregering

Även om dataaggregering skapar bra användarupplevelser, som en plattformstekniker uttryckte det:

Automatisering är nyckeln och kommer att älskas av alla. [Data] aggregering är sekundär. – Peter, plattformsteknik lead, multinationell tech företag

Därför är det troligt att den plattformstekniska resa som du har kartlagt har identifierat några problem som kan lösas med automatisering. Förutom att minska den kognitiva belastningen och utvecklararbetet kan automatisering även hjälpa till att säkerställa att program ä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 fler ä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 ofta börja med att länka till externa system för att uppfylla andra behov eller för detaljerad information. Dataaggregering och synlighet är också viktigt för granskning, styrning och minskning av avfall (till exempel oanvända miljöer).

Automatisering av 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 stadierna av din plattform, för nya produkter som du för 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 i stil med 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.

Med tanke på ett produkttänk och idén om en tunnaste fungerande plattform (TVP) (en MVP för din plattform) bör du börja enkelt genom att återanvända befintliga investeringar som dina tekniska system eller en intern portal, sedan skapa CLI:er, grundläggande webbsidor eller till och med Power Pages, Power BI eller Microsoft Fabric-instrumentpaneler och expandera när behovet uppstår. Med det i åtanke kan ett konsekvent API som UX sedan använder hjälpa dig att stödja flera gränssnitt över tid när dina behov och inställningar ändras.

Översikt över begrepp

Tänk på följande bild:

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

Med dessa grundläggande komponenter kan du använda och byta ut olika byggstenar över tid. Vi går igenom vart och ett av dessa i detalj i efterföljande avsnitt.

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

Nej. För det första är detta en konceptuell modell som hjälper dig att tänka igenom vad en grund som denna bör kunna göra när den är klar. För det andra är implementeringsspecifika mindre viktiga här med tanke på att API:et för utvecklarplattformen blir ditt nyckelgränssnitt. Din första implementering kan börja använda gränssnitt och klasser i koden för de olika lager som beskrivs eller blandas i 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.

Med det i åtanke ska vi gräva djupare i varje del.

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 bör också fungera som ett viktigt autentiserings- och säkerhetslager genom att begränsa åtkomsten till underliggande API:er i andra system till mer specifika, kontrollerade data och åtgärder. API:et ger åtkomst till en egen representation av en användarprofil, en användares övergripande roll inom plattformen (gruppmedlem, 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 rekommenderar vi att du skapar eller letar efter system som följer en utökningsbar leverantörsmodell för att introducera funktioner i API:et. Tanken är att viktiga funktioner som automatisering och dataaggregering tillhandahålls genom interaktion med anslutningsbara komponenter med väldefinierade gränssnitt. Den här lösa kopplingen hjälper dig att koppla in det du behöver inkrementellt 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. Normalt misslyckas arbetet med inre inköp kring plattformsteknik att få dragkraft på grund av utmaningar med pågående 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. Däremot har alla centraliserade team begränsad kapacitet för att underhålla kod som har bidragit eller till och med granska pull-begäranden. Konceptet med en leverantör av utvecklarplattform minskar den här spänningen genom att låta fristående skriven kod "ansluta" till kärnfunktioner i din självbetjäningsgrund för utvecklare. Ä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 över en bredare del av organisationen.

Viktiga leverantörskoncept för utvecklarplattformen

Enheter

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

• Visas externt etablerade resurser/miljöer eller tillgängliga API:er för identifiering och användning
• Exponera relationer för beroendeanalys, effektanalys, identifiering osv.
• Ytunderhållare/ägarskapsinformation för identifiering och samarbete
• Yttring av mer data 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 fortfarande vill 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.

Vanliga egenskaper

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

• Unik identifierare
• Namn
• Ursprungsprovider
• Valfria associationer för att:
  • Ägande användare
  • Ägande team
  • Andra entiteter

Användar- och teamegenskaperna är viktiga av tre skäl: rollbaserad åtkomstkontroll (RBAC), identifiering och dataaggregering (till exempel sammanfattningar på teamnivå). Att bygga in RBAC från början är viktigt för säkerheten och att utveckla din interna utvecklarplattform över tid. Med tanke på att utveckling ä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:

• Miljöer
• Resurser
• Api
• Databaser
• Komponenter
• Verktyg

Dessa bör vanligtvis vara på en hög nivå, som du skulle placera i C4-modellkontexten eller på de flesta komponentdiagram på hög nivå. 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 systemet i stället för att försöka använda 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 driva 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 utvecklarplattformsleverantörer och bör ha stöd för 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 (starta höger) eller malllagringsplatser
• Skapa pipeline/arbetsflödesmallar
• Distributionspipeline/arbetsflödesmallar
• Parametriserade skript
• Parameteriserade Power Automate-flöden (exempel: en HTTP-begäran utlöste molnflöde)
• Email mallar

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, parametriserade 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 azure-distributionsmiljöer. Andra IaC-mallar kan lagras i ett OCI Artifact Registry som Helm-diagram. I andra fall kan mallen vara en referens till en parametriserad HTTP-slutpunkt. En leverantör av utvecklarplattform bör ge precis 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 förvaras på den mest naturliga platsen för dina användningsfall.

Plattformstekniker eller experter på ett visst område skriver dessa mallar och delar dem sedan med utvecklingsteam för återanvändning. Genom att centralisera användningen av dessa mallar via ett system kan utvecklare självbetjäna och skapa skyddsräcken som hjälper till att genomdriva efterlevnad av organisationens standarder eller principer. Mer om detta när vi täcker utvecklarplattformsorkestreraren på lite sätt.

Utvecklarplattformsgrafen

Du kan se ett diagram för utvecklarplattformen 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 med 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 leverantör av utvecklarplattform 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 power discovery, sökning, styrning med mera. En utvecklarplattformsorkestrerare kan sedan dra nytta av samma graf 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.

Utvecklarplattformsorkestrerare

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 dessa åtgärder, utan samordnar i stället med en uppgiftsmotor, arbetsflödesmotor eller någon annan orkestrerare för att göra det. Det är en av de viktigaste delarna som du vill vara säker på är en del av din självbetjäningsgrund. 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.

Enligt beskrivningen i Tillämpa programvarutekniksystem kan du 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 skäl:

• Först vill du förmodligen kunna välja olika arbetsflödes- och aktivitetskörningsmotorer över tid utan att behöva blixtsnika. 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 inledningsvis ä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 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 skala upp något som kan GitHub Actions eller Azure Pipelines.

Som tur är kan en utökning av idén om en leverantör av utvecklarplattformen för att täcka automatiseringssteg för utlösande och spårning tillhandahålla den här abstraktionen. Tänk på följande bild:

Här är det allmänna konceptet:

1. 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.
2. En referens till mallrelaterade indata blir en begäran i API:et för utvecklarplattformen.
3. När en begäran har skickats börjar en komponent för routning och hantering av begäran i orkestreraren spåra begärans livscykel. Mallen för routning och hantering av komponentvägar i begäran till utvecklarplattformsprovidern där mallen har sitt ursprung.
4. Utvecklarplattformsleverantören skulle sedan utföra lämpliga steg för implementeringen.
5. [Valfritt] Utvecklarplattformsprovidern uppdaterar begärans status när den utför åtgärden.
6. När begäran har uppfyllts kan utvecklarplattformsprovidern returnera en uppsättning entiteter för att lägga till/uppdatera i grafen för utvecklarplattformen. Dessa kan vara providerspecifika eller vanliga entiteter.

Om du vill ha stöd för mer avancerade interaktioner kan du låta dessa leverantörer av utvecklarplattformen 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.

Även om den specifika lösningen eller en produkt som du utvärderar kan variera, bör detta ge dig en uppfattning om egenskaperna att leta efter.

Med detta i åtanke vill du ha en leverantör för utvecklarplattformen som använder en allmän uppgifts- eller arbetsflödesmotor. Mer specifikt vill du ha något som överbryggar det du har satt ihop som en del av Tillämpa programvarutekniksystem. En allmän arbetsflödes- eller uppgiftskörningsmotor som du förmodligen kommer att investera i är ditt 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 har stöd för en uppsättning indata genom att lägga till en workflow_dispatch konfiguration i YAML-arbetsflödesfilen. Azure DevOps-utlösare är liknande och du kan också använda Azure DevOps Pipeline-API :et för körningar. Du kommer förmodligen att se samma funktioner i andra produkter.

Dessa arbetsflöden/pipelines behöver inte finnas i programmets källkodslagringsplatser. Konceptet skulle vara att dra nytta av detta faktum för att göra något som liknar detta:

1. 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 används av arbetsflöden/pipelines.
2. Om du vill tillåta att dessa arbetsflöden/pipelines interagerar med lämpligt nedströmssystem kan ops eller andra medlemmar i ditt plattformsteknikteam lägga till nödvändiga hemligheter på den centrala lagringsplatsen. Mer information om hur du gör detta finns i dokumentationen om GitHub Actions och Azure DevOps, eller så kan du välja att centralisera hemligheterna med något som Azure Key Vault.
3. Dessa arbetsflöden/pipelines kan sedan följa en modell där de publicerar resulterande entiteter som en bygg-/distributionsartefakt (GitHub-dokument, Azure DevOps-dokument).
4. Under en körning kan utvecklarplattformsprovidern sedan watch tillståndet för arbetsflödet/pipelinen och uppdatera livscykelstatusen i orkestreraren tills den är klar. Du kan till exempel använda webhookar med GitHub Actions och tjänstkrokar med Azure Pipelines för att spåra uppdateringar.
5. När det är klart kan providern sedan använda den publicerade artefakten för inkludering i utvecklarplattformsgrafen 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 ditt CI/CD-system är att de ofta är konfigurerade för att stödja körning av godtyckliga CLIs, så du behöver inte en förstklassig, unik integrering 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 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 leverantörer av utvecklarplattform som kan bearbeta mallar.

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

Användare och team

Plattformsteknik är i sig 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. I det här avsnittet går vi igenom en strategi för att hantera vanliga utmaningar med identitet, användare och team.

Överväg först dessa två rekommendationer:

Härnäst ska vi bygga upp från dessa rekommendationer för att skapa en modell för hantering av mer utmanande problem i det här utrymmet.

Etablera konceptet med ett team utöver en enda identitetsprovidergrupp

När din plattformsteknik 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 rollbaserad åtkomstkontroll (RBAC) och dataaggregering.

Inom ramen för plattformsteknik definierar vi ett team som en uppsättning personer i olika roller som arbetar tillsammans. För dataaggregering är idén om ett team med flera roller avgörande för att skapa information om identifiering och sammanslagning på platser som rapportering av instrumentpaneler. Å 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 för dina teamdata kan komma från några olika platser. Om du till exempel använder teamen som kodmönster (TaC) kan en leverantör av utvecklarplattform watch för filändringar på en lagringsplats och cachelagrat dem i ett användarprofil- och teammetadatalager. Eller så kan du integrera direkt med något som liknar ett Azure Dev Center-projekt som redan har dessa kärn-RBAC-konstruktioner tillgängliga.

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

Även om vissa utvecklar- och åtgärdsverktyg/-tjänster integrerar och använder identitetsproviderkoncept direkt, kommer många att abstrahera detta till sin egen representation av en grupp eller användare (även med enkel inloggning). Förutom att aktivera åtkomst mellan olika verktyg kan den här verkligheten också orsaka 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 (exempel: Objekt-ID i Entra-ID används inte 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.

Hantera 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 teamet som det brukade göra det.

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

Om du föredrar att använda en annan datakälla än filer på en lagringsplats kan du använda samma allmänna koncept med hjälp av utvecklarplattformsorkestreraren för att åstadkomma samma sak. Enligt den här modellen kan en leverantör av utvecklarplattformen 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 återigen vara till hjälp att lagra en mappning för ett användar-ID som har åtkomst till data via UTVECKLARplattformens API. Överväg till exempel GitHub:

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

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

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

1. Utvecklarplattforms-API:et kan ha stöd för en cache med providerspecifika användartoken för användning med underordnade system.
2. Alla interaktioner med en viss provider som utlöses av API:et skulle inkludera i providerns användartoken om det är tillgängligt.
3. 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 ett.
4. 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 skickas in innehåller en nonce-/engångskod.
5. API:et returnerar sedan ett "inte autentiserat" svar med URI:n.
6. Valfritt UX kan sedan använda den här URI:n för att driva rätt autentiseringsflöde i en webbläsare.
7. När omdirigeringen sker får utvecklarplattformen den användartoken som behövs och cachelagras för framtida referens tillsammans med användar-ID:t.
8. 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.

Aggregera data och tillhandahålla extra funktioner

Använda sammanhangsmedvetna djuplänkar till verktyg och rapporteringssystem

Fram tills nu har vi talat om automatiseringsaspekten av problemutrymmet. Det här kan ta lång tid 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 leverantörer av utvecklarplattformen generera alla typer av entitetsbehov. Vanligtvis vill du dock inte ta med alla detaljerade data i hela den interna utvecklarplattformen 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 mycket 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.

I fall där du vill ha aggregerade och sammanfattade data mellan verktyg eller behöver köra anpassade mått kan rapportlösningarna Power BI eller Microsoft Fabric vara din nästa anropsport. Om du vill slå samman teamdata kan du antingen ansluta till foundations databas eller gå igenom ett API för utvecklarplattformen. Till exempel, enligt beskrivningen i Planera och prioritera, är en plats där du kanske vill ha en anpassad instrumentpanel 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 tänk på att du också måste underhålla den. Det här är det område där det är viktigt att följa ett produkttänk. Gränssnitt för instrumentpanelsformat är enkla att tänka ut och förstå, men dina utvecklare kan hitta 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 utvecklarplattformens API omfångsutdata (tillsammans med indexering och cachelagring).

Men även om du behöver skapa anpassat UX i stället för en djuplänk är det vanligtvis inte den bästa metoden att hämta alla data till ditt plattformsdiagram för utvecklare. Tänk dig till exempel en situation där du kanske vill visa loggar i ditt UX som redan har ett väldefinierat och hanterat hem. Använd information i relaterade entiteter för att hjälpa ditt UX 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 följer några exempel på vanliga upplevelser att tänka på:

Användarupplevelser

Olika roller i din organisation har verktyg eller tjänster som utgör en tyngdpunkt för det dagliga arbetet. Hämtningen av dessa system kan göra det svårt för nya användarupplevelser utanför dessa tyngdpunkter att få dragkraft. I en perfekt värld kan utvecklare, åtgärder och andra roller fortsätta att arbeta 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 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 programplattformen 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 folk att reagera bättre på en annan ny användarupplevelse eller en förbättrad version av något de har nu?)

Några 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 får stor nytta av att börja där. Detta kan eliminera underhåll och säkerhetshuvudvärk och låta dig 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.
• CLIs blir alltmer utökningsbara också.
• 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 utvecklarplattformen som baslinje kan du byta 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 komma ihåg 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.

Utöver 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 dina utvecklare 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 även 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 att 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-programplattformar har inbyggda 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 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 det här arbetet. Alla organisationer är olika, så det finns inget svar som passar alla för vad som ska finnas i den här typen av upplevelse. Som ett resultat finns det inget defacto-svar för en färdigförpackad produkt som du kan starta och använda som den är för något som detta idag.

För anpassade lokala alternativ är allmänna webbportalramverk inte nya och dina utvecklingsteam kanske redan använder ett som du kan utnyttja. Om du försöker få ut något framför användarna för tidig feedback kan du till och med börja med något så enkelt som Power Pages med lite kod för att ansluta till ett gemensamt API för utvecklarplattformen.

Nyare ansträngningar för utvecklarportalen ä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 på samma sätt som create-react-app gör för React.js.

Som portalverktyg kräver det arbete för att komma igång och anpassning kräver kunskaper om TypeScript, Node.js och React. Men det fantastiska med det är att du som verktyg kan ändra nästan vad som helst. Det har sin egen programvara katalog och mallning mekanism också, men deras användning krävs inte, och det har väldefinierade sätt att ta in nya 1^st och 3^rd part kod som kallas plugins.