Plattformsarkitektur för utvecklare
En självbetjäningsupplevelse för utvecklare förlitar sig på en kombination av begrepp, mönster och verktyg, som omfattar specialbyggda, färdiga tekniker och tekniker med öppen källkod. Målet är att ge utvecklare styrning av uppgiftskörning och etablering samtidigt som centraliserad synlighet bibehålls. Primärt fokus bör ligga på uppgifter som antingen är omständliga eller för komplexa för utvecklare att hantera oberoende av varandra.
Komponenter för självbetjäningsplattform för utvecklare
En självbetjäningsgrund för utvecklare består av flera viktiga komponenter som fungerar tillsammans för att effektivisera och automatisera utvecklararbetsflöden. Dessa komponenter omfattar API:et developer platform, developer platform graph, developer platform orchestrator, developer platform providers och användarprofil och teammetadata.
API:et developer platform fungerar som den centrala interaktionspunkten och fungerar som ett avtalsgränssnitt mellan användarupplevelser och andra system. Ett API för utvecklarplattform bör aktivera dataåtkomst och driva etableringsåtgärder via olika användargränssnitt. Det fungerar som det primära autentiserings- och säkerhetsskiktet, vilket begränsar åtkomsten till underliggande, råa API:er tillsammans med motsvarande data och åtgärder. API:et hanterar användarprofiler, roller inom plattformen och primära identitetsprovideridentifierare för att säkerställa korrekt åtkomstkontroll.
Ett komplement till API:et för utvecklarplattformen är Developer Platform Graph, en säker, hanterad datastruktur som underlättar identifiering och association av entiteter och mallar inom plattformen. Entiteter aggregerar data från flera källor, medan mallar vägleder användarindata för automatisering.
Med Developer Platform Graph kan du associera entiteter och mallar från flera leverantörer till en sökbar struktur. Även om data för dessa entiteter inte behöver lagras direkt i en grafdatabas, kan interaktioner med leverantörer cachelagras tillsammans med nödvändiga metadata. Det här diagrammet blir särskilt värdefullt när du arbetar med vanliga entiteter som flera leverantörer bidrar med. API:er kan till exempel komma från Azure API Center, medan distributioner och miljöer kan hämtas från system för kontinuerlig distribution. Diagrammet driver användarupplevelser via ett gemensamt API som möjliggör identifiering, sökning och styrning.
För att köra mallbaserade åtgärder dirigerar och spårar Developer Platform Orchestrator begäranden och samordnar med specialiserade leverantörer av utvecklarplattform som integreras med underordnade system. Orchestrator gör det möjligt för utvecklare eller system att begära åtgärder med hjälp av mallar, utan att utföra åtgärderna direkt. Den samordnar med en uppgiftsmotor, arbetsflödesmotor eller en annan orkestrerare för att utföra åtgärderna. Den här komponenten är viktig för att aktivera självbetjäning, eftersom den gör det möjligt för utvecklare att utlösa åtgärder utan att behöva direkta behörigheter. Till skillnad från CI/CD är dessa åtgärder inte begränsade till programmets källkod. Arbetsflödesmotorer som GitHub Actions eller Azure Pipelines kan fungera som orkestrerare, men abstraktion kan vara användbart för att stödja olika motorer över tid. Den här flexibiliteten möjliggör motormigrering, stöder manuella steg för processer som senare kan automatiseras och hanterar åtgärder som riktar sig mot icke-utvecklingsroller (till exempel leverantörsreskontra). Dessutom kan enklare uppgifter hanteras via HTTP-begäranden, vilket undviker behovet av komplexa motorer.
Utvecklarplattformsleverantörer hanterar logiken för crud-åtgärder (Create, Read, Update och Delete) på entiteter och körning av åtgärdsbegäranden, med stöd för olika arbetsflöden och tjänster. Leverantörerna introducerar funktioner i API:et via en utökningsbar providermodell, vilket möjliggör viktiga funktioner som automatisering och dataaggregering. Den här modellen främjar lös koppling, vilket möjliggör inkrementell integrering av nya funktioner och förbättrar underhållsbarheten. Genom att främja en inre källmentalitet kan plattformsfunktioner bidra och underhållas av olika team, vilket minimerar underhållsbördan för centrala team. Det är viktigt att granska providerkoden och hantera åtkomsten noggrant, men den här pluggbara metoden hjälper till att skala utvecklingsarbetet i hela organisationen.
Grunden innehåller även funktioner för att hantera användarprofil och teammetadata, som kopplar individuell information och teaminformation till konton som hanteras av en identitetsprovider, till exempel Microsoft Entra-ID. Dessa metadata används för gruppering och åtkomstkontroll i utvecklarplattforms-API:et. Det skulle vara möjligt att lagra den här informationen i Developer Platform Graph, men om du separerar den blir den tydligare.
En självbetjäningsgrund för utvecklare är tillgänglig via ett centraliserat användargränssnitt/användarupplevelse (UI/UX). Att erbjuda en enhetlig åtkomstpunkt effektiviserar interaktioner för utvecklare, vilket underlättar användningen av arbetsflöden och resurser på ett sömlöst och intuitivt sätt.
En självbetjäningsgrund för utvecklare behöver inte byggas helt från början. I stället fungerar den som en konceptuell guide för de funktioner som du kan sikta på över tid. Inledande implementeringar kan förenklas med hjälp av befintliga verktyg, gränssnitt eller klasser för att hantera de mest akuta prioriteringar som identifierats genom kundfeedback. Genom att börja litet och iterera kan grunden utvecklas för att effektivt uppfylla nya krav.
Viktiga begrepp för plattformsleverantör för utvecklare
På en utvecklarplattform är effektiv hantering och orkestrering av resurser beroende av användning av entiteter tillsammans med deras egenskaper och mallar. De här nyckelbegreppen ger struktur och automatisering, möjliggör sömlös integrering mellan olika leverantörer och underlättar konsekventa arbetsflöden och styrning.
Entiteter
Entiteter är de viktigaste objekt som en utvecklare eller ett system behöver för att spåra, uppdatera, presentera eller agera på inom den interna utvecklarplattformen. Dessa entiteter kan ha relationer med varandra och bilda ett diagram som ger viktig information om plattformen. Utvecklares plattformsleverantörer kan mata ut entiteter för att stödja olika kärnfunktioner, till exempel identifiera externa resurser, utföra beroendeanalyser eller visa ägarskap och underhållsinformation. Ett väldefinierat providergränssnitt förenklar integrering, testning och distribution samtidigt som utvecklarteamen kan arbeta oberoende av varandra.
Gemensamma egenskaper
För att effektivt hantera entiteter är det bra att definiera en uppsättning vanliga egenskaper. Några föreslagna egenskaper är en unik identifierare, ett namn, en leverantör och valfria associationer till användare, team eller andra entiteter. Dessa egenskaper är viktiga för rollbaserad åtkomstkontroll (RBAC), identifiering och dataaggregering. Att implementera RBAC från början är viktigt för säkerhet och skalning av plattformen över tid. Användar- och teamassociationer är särskilt värdefulla eftersom de hjälper till med identifiering och samarbete, vilket möjliggör effektiv återanvändning, support och inre källor inom plattformen.
Vanliga och providerspecifika entiteter
Du bör också definiera en uppsättning vanliga normaliserade entiteter på hög nivå som flera leverantörer kan mata ut. Dessa kan omfatta miljöer, resurser, API:er, lagringsplatser, komponenter och verktyg. Dessa entiteter bör vara konceptuella och fokusera på den breda kategoriseringen (till exempel miljöer) snarare än detaljerad teknisk information (till exempel intern infrastruktur). Den här vyn på hög nivå underlättar identifiering, aktiverar dataaggregering över tid och pekar på information på lägre nivå utanför systemet. När din plattform utvecklas kan du dessutom behöva hantera en växande uppsättning leverantörsspecifika entitetstyper för att uppfylla olika användningsfall.
Mallar
Mallar är utformade för att driva åtgärder som infrastrukturetablering, skapande av lagringsplatser eller andra tidskrävande processer. Dessa mallar är tillgängliga via utvecklarplattformsleverantörer och innehåller vanliga egenskaper som entitetsassociationer och nödvändiga indata (till exempel resursnamn). Mallar kan representera olika format, inklusive IaC-mallar (Infrastructure-as-Code), programmallar eller parametriserade skript. De är ofta leverantörsspecifika, med olika representationer beroende på vilken teknik som används. Exempel på dessa representationer är Terraform- eller Bicep-mallar, Helm-diagram, parameteriserade GitHub Actions-arbetsflöden, Azure Pipelines, enkla skript eller anpassade format som är skräddarsydda för specifika providerekosystem.
Även om mallar inte behöver lagras centralt måste de vara tillgängliga via en provider för att säkerställa konsekvent åtkomst över hela plattformen. De kan finnas i olika lagringsplatser, register eller kataloger beroende på användningsfallet. Till exempel kan GitHub-malllagringsplatser användas för programmallar, medan IaC-mallar kan finnas i en begränsad kataloglagringsplats som utvecklare indirekt kommer åt via verktyg som Azure Deployment Environments. Andra IaC-mallar kan lagras i ett OCI-artefaktregister (Open Container Initiative), till exempel Helm-diagram. I vissa fall kan en mall bara referera till en parameteriserad HTTP-slutpunkt.
Plattformstekniker eller domänspecialister skapar vanligtvis dessa mallar och delar dem med utvecklingsteam för återanvändning. Att centralisera användningen av mallar i ett system underlättar deras åtkomst samtidigt som organisationens standarder och principer upprätthålls. Den här processen hjälper till att upprätthålla kontroll och efterlevnad på plattformen samtidigt som utvecklare kan arbeta mer effektivt.
GitHub Actions som plattformsproviders
För att illustrera hur en leverantör fungerar ska vi överväga GitHub Actions och Azure Pipelines. Någon av dem kan fungera som plattformsleverantör för utvecklare genom att utlösa arbetsflöden eller pipelinekörningar via sina respektive API:er, till exempel GitHub Actions REST API eller Azure DevOps Pipeline API. Dessa arbetsflöden eller pipelines behöver inte lagras i programkällans lagringsplatser, vilket gör det möjligt för plattformstekniker att underhålla dem i centrala, privata lagringsplatser. I den här modellen har utvecklare inte direkt åtkomst till arbetsflödena, men kan använda en leverantör av utvecklarplattform för att interagera med dem. Providern kan hantera nödvändiga hemligheter, till exempel autentiseringsuppgifter eller API-nycklar, genom att integrera med tjänster som Azure Key Vault. När arbetsflöden körs spårar providern deras tillstånd med hjälp av webhooks för GitHub Actions och tjänstkrokar för Azure Pipelines för att övervaka förloppet. När arbetsflödet har slutförts samlas alla artefakter som skapas, till exempel bygg- eller distributionsresultat, in och ut. Dessa artefakter, tillsammans med indataparametrar och referenser till arbetsflödena, kan läggas till i utvecklarplattformsgrafen. Den här metoden ger också flexibilitet när det gäller att använda godtyckliga CLI:er, vilket stöder en mängd olika automatiseringsuppgifter över tid. Dessutom är användningen av GitHub Actions eller Azure Pipelines i det här sammanhanget oberoende av deras traditionella roll i CI/CD, vilket ger bredare tillämplighet för att hantera olika processer och mallar.
Diagram som visar Utvecklarplattformens API, Utvecklarplattformens Orchestrator och GitHub Actions-leverantören.
Det finns andra typer av utvecklare plattformsleverantörer, som kan hantera olika uppgifter via mallar. För källkontrollåtgärder kan leverantörer hjälpa till att hantera Git-uppgifter som att skapa lagringsplatser, skicka PR eller andra Git-åtgärder utan att förlita sig på allmänna arbetsflödesmotorer. Infrastrukturetablering kan effektiviseras genom dedikerade leverantörer som Azure Deployment Environments eller Terraform Cloud, med fokus på infrastruktur som kod (IaC) med säkerhet och effektivitet. Leverantörer av programställningar, till exempel Azure Developer CLI, har stöd för att skapa programkällans träd och push-överföra dem till källlagringsplatser, vilket ger flexibilitet för olika ekosystem. Manuella processer, till exempel att generera pull-begäranden (PR) eller automatisera arbetsflöden för icke-utvecklare, kan också hanteras via mallbaserade leverantörer, vilket möjliggör gradvis automatisering. De här exemplen belyser hur utökningsbarhet och anpassningsbarhet hos utvecklarplattformsleverantörer kan förbättra automatiseringsfunktionerna över tid.