Arkitektur af udvikler-Self-Service-platform
En selvbetjeningsoplevelse for udviklere er afhængig af en kombination af begreber, mønstre og værktøjer, der spænder over specialbyggede, off-the-shelf- og open source-teknologier. Målet er at give udviklere med styret udførelse og klargøring af opgaver, samtidig med at den centraliserede synlighed bevares. Det primære fokus skal være på opgaver, der enten er kedelige eller for komplekse til, at udviklere kan håndtere dem uafhængigt af hinanden.
Komponenter til udvikler- Self-Service platform
Et selvbetjeningsfundament til udviklere består af flere vigtige komponenter, der arbejder sammen om at strømline og automatisere udviklerarbejdsprocesser. Disse komponenter omfatter API-tiludviklerplatform , Graph-for udviklerplatform , developer platform Orchestrator, udbydere af udviklerplatformog for brugerprofiler og teammetadata .
API-til udviklerplatform fungerer som det centrale element i interaktionen og fungerer som en kontraktlig grænseflade mellem brugeroplevelser og andre systemer. En API til udviklerplatform skal muliggøre dataadgang og køre klargøringshandlinger via forskellige brugergrænseflader. Det fungerer som det primære godkendelses- og sikkerhedslag, der begrænser adgangen til underliggende rå API'er sammen med de tilsvarende data og handlinger. API'en administrerer brugerprofiler, roller på platformen og primære id'er for identitetsudbydere for at sikre korrekt adgangskontrol.
Komplementerer API'en til udviklerplatformen er Developer Platform Graph, en sikker, administreret datastruktur, der faciliterer registrering og tilknytning af objekter og skabeloner på platformen. Objekter aggregerer data fra flere kilder, mens skabeloner guider brugerinput til automatisering.
Med Developer Platform Graph kan du knytte objekter og skabeloner fra flere udbydere til en struktur, der kan søges i. Selvom dataene for disse enheder ikke behøver at blive gemt direkte i en grafdatabase, kan interaktioner med providere cachelagres sammen med nødvendige metadata. Denne graf bliver især værdifuld, når du arbejder med almindelige enheder, der er bidraget af flere udbydere. API'er kan f.eks. komme fra Azure API Center, mens udrulninger og miljøer kan hentes fra fortløbende udrulningssystemer. Grafen styrer brugeroplevelser via en fælles API, der muliggør søgning, søgning og styring.
Hvis du vil udføre skabelonbaserede handlinger, Developer Platform Orchestrator distribuerer og sporer anmodninger og koordinerer med specialiserede udbydere af udviklerplatform, der integreres med downstream-systemer. Orchestrator gør det muligt for udviklere eller systemer at anmode om handlinger ved hjælp af skabeloner uden at udføre handlingerne direkte. Den koordinerer med et opgaveprogram, et arbejdsprocesprogram eller en anden orchestrator for at udføre handlingerne. Denne komponent er vigtig for at aktivere selvbetjening, da den gør det muligt for udviklere at udløse handlinger uden at have direkte tilladelser. I modsætning til CI/CD er disse handlinger ikke begrænset til programkildekode. Arbejdsprocesprogrammer som GitHub-handlinger eller Azure Pipelines kan fungere som orkestrere, men abstraktion kan være nyttigt til at understøtte forskellige motorer over tid. Denne fleksibilitet giver mulighed for programoverførsel, understøtter manuelle trin for processer, der senere kan automatiseres, og imødekommer handlinger, der er målrettet til ikke-udviklingsroller (f.eks. kreditor). Derudover kan enklere opgaver håndteres via HTTP-anmodninger, så du undgår behovet for komplekse motorer.
udbydere af udviklerplatform administrere logikken for handlingerne Create, Read, Update og Delete (CRUD) på objekter og udførelse af handlingsanmodninger, der understøtter forskellige arbejdsprocesser og tjenester. Udbyderne introducerer funktionalitet i API'en via en providermodel, der kan udvides, hvilket muliggør vigtige funktioner som automatisering og datasammenlægning. Denne model fremmer løs kobling, hvilket giver mulighed for trinvis integration af ny funktionalitet og forbedring af vedligeholdelsen. Ved at skabe en mentalitet i en indre kilde kan platformfunktionaliteten bidrage og vedligeholdes af forskellige teams, så vedligeholdelsesbyrden på centrale teams minimeres. Selvom det er vigtigt at gennemgå udbyderkoden og administrere adgangen omhyggeligt, hjælper denne tilslutningsbare tilgang med at skalere udviklingsindsatsen på tværs af organisationen.
Fundamentet indeholder også funktioner til administration af brugerprofil og teammetadata, som knytter individuelle oplysninger og teamoplysninger til konti, der hostes af en identitetsudbyder, f.eks. Microsoft Entra ID. Disse metadata bruges til gruppering og adgangskontrol i API'en til udviklerplatformen. Selvom det ville være muligt at gemme disse oplysninger i Grafen for udviklerplatformen, sikrer adskillelsen af dem klarhed.
Et selvbetjeningsfundament til udviklere er tilgængeligt via en centraliseret brugergrænseflade/brugeroplevelse (brugergrænseflade/UX). Med et samlet adgangspunkt strømlines interaktioner for udviklere, hvilket letter brugen af arbejdsprocesser og ressourcer på en problemfri og intuitiv måde.
Et selvbetjeningsfundament til udviklere behøver ikke at være fuldt bygget fra starten. I stedet fungerer den som en konceptuel vejledning til de funktioner, der skal sigtes efter over tid. Indledende implementeringer kan forenkles ved hjælp af eksisterende værktøjer, grænseflader eller klasser til at håndtere de mest presserende prioriteter, der er identificeret via kundefeedback. Ved at starte små og gentage, kan fundamentet udvikle sig til effektivt at opfylde nye krav.
Vigtige koncepter for udbyder af udviklerplatform
I en udviklerplatform er effektiv administration og orkestrering af ressourcer afhængig af brugen af enheder sammen med deres egenskaber og skabeloner. Disse nøglebegreber giver struktur og automatisering, hvilket muliggør problemfri integration på tværs af forskellige udbydere og faciliterer ensartede arbejdsprocesser og styring.
Enheder
Objekter er de vigtigste objekter, som en udvikler eller et system skal spore, opdatere, præsentere eller reagere på i den interne udviklerplatform. Disse enheder kan have relationer til hinanden og danne en graf, der giver vigtige oplysninger om platformen. Udbydere af udviklerplatform kan sende enheder for at understøtte forskellige kernefunktioner, f.eks. finde eksterne ressourcer, udføre afhængighedsanalyse eller vise ejerskabs- og vedligeholdelsesoplysninger. En veldefineret providergrænseflade forenkler integration, test og udrulning, samtidig med at udviklerteams kan fungere uafhængigt af hinanden.
Almindelige egenskaber
Hvis du vil administrere objekter effektivt, er det nyttigt at definere et sæt fælles egenskaber. Nogle foreslåede egenskaber omfatter et entydigt id, et navn, en oprindelsesprovider og valgfri tilknytninger til brugere, teams eller andre enheder. Disse egenskaber er vigtige for rollebaseret adgangskontrol (RBAC), registrering og datasammenlægning. Implementering af RBAC fra starten er afgørende for sikkerheden og skaleringen af platformen over tid. Bruger- og teamtilknytninger er især værdifulde, da de hjælper med at finde og samarbejde, hvilket muliggør effektiv genbrug, support og indre sourcing på platformen.
Almindelige enheder og providerspecifikke enheder
Du bør også definere et sæt almindelige, normaliserede objekter på højt niveau, som flere udbydere kan oprette. Disse kan omfatte miljøer, ressourcer, API'er, lagre, komponenter og værktøjer. Disse enheder skal være konceptuelle og fokusere på den brede kategorisering (f.eks. miljøer) i stedet for de detaljerede tekniske detaljer (f.eks. intern infrastruktur). Denne visning på højt niveau faciliterer registrering, hvilket muliggør datasammenlægning over tid, samtidig med at der peges på detaljer på lavere niveau uden for systemet. I takt med at din platform udvikler sig, kan det desuden være nødvendigt at imødekomme et voksende sæt providerspecifikke objekttyper for at imødekomme forskellige use cases.
Skabeloner
Skabeloner er udviklet til at drive handlinger som f.eks. klargøring af infrastruktur, oprettelse af lagre eller andre langvarige processer. Disse skabeloner er tilgængelige via udbydere af udviklerplatform og omfatter almindelige egenskaber, f.eks. enhedstilknytninger og påkrævede input (f.eks. ressourcenavne). Skabeloner kan repræsentere forskellige formater, herunder IaC-skabeloner (Infrastructure-as-Code), programskabeloner eller parameteriserede scripts. De er ofte providerspecifikke med forskellige repræsentationer afhængigt af den teknologi, der er i brug. Eksempler på disse repræsentationer omfatter Terraform- eller Bicep-skabeloner, Helm-diagrammer, gitHub-handlingsarbejdsprocesser, Azure Pipelines, enkle scripts eller brugerdefinerede formater, der er skræddersyet til specifikke providerøkosystemer.
Selvom skabeloner ikke behøver at blive gemt centralt, skal de være tilgængelige via en udbyder for at sikre ensartet adgang på tværs af platformen. De kan findes i forskellige lagre, registre eller kataloger, afhængigt af use case. GitHub-skabelonlagre kan f.eks. bruges til programskabeloner, mens IaC-skabeloner kan være placeret i et begrænset kataloglager, som udviklere får adgang til indirekte via værktøjer som Azure Deployment Environments. Andre IaC-skabeloner kan være gemt i en OCI-registreringsdatabase (Open Container Initiative), f.eks. Helm-diagrammer. I nogle tilfælde refererer en skabelon muligvis blot til et parameteriseret HTTP-slutpunkt.
Platformteknikere eller domænespecialister opretter typisk disse skabeloner og deler dem med udviklingsteams til genbrug. Centralisering af brugen af skabeloner i et system letter deres adgang, samtidig med at organisationens standarder og politikker gennemtvinges. Denne proces hjælper med at opretholde kontrol og overholdelse af angivne standarder på tværs af platformen, samtidig med at udviklere kan arbejde mere effektivt.
GitHub-handlinger som platformudbydere
Lad os se på GitHub-handlinger og Azure Pipelines for at illustrere, hvordan en udbyder fungerer. En af dem kan fungere som udbyder af udviklerplatform ved at udløse arbejdsprocesser eller pipelinekørsler via deres respektive API'er, f.eks. GitHub Actions REST API eller Azure DevOps Pipeline API. Disse arbejdsprocesser eller pipelines er ikke påkrævet for at være lagret i programkildekodelagre, hvilket gør det muligt for platformteknikere at vedligeholde dem i centrale, private lagre. I denne model har udviklere ikke direkte adgang til arbejdsprocesserne, men kan bruge en udbyder af udviklerplatform til at interagere med dem. Udbyderen kan administrere nødvendige hemmeligheder, f.eks. legitimationsoplysninger eller API-nøgler, ved at integrere med tjenester som Azure Key Vault. Når arbejdsprocesser udføres, sporer udbyderen deres tilstand ved hjælp af webhooks til GitHub-handlinger og tjeneste hooks til Azure Pipelines for at overvåge status. Når arbejdsprocessen er fuldført, registreres og publiceres alle de artefakter, der oprettes, f.eks. build- eller udrulningsresultater. Disse artefakter kan sammen med inputparametre og referencer til arbejdsprocesser føjes til grafen for udviklerplatformen. Denne fremgangsmåde giver også mulighed for fleksibilitet i brugen af vilkårlige NØGLETAL, der understøtter en lang række automatiseringsopgaver over tid. Derudover er brugen af GitHub-handlinger eller Azure Pipelines i denne kontekst uafhængig af deres traditionelle rolle i CI/CD, hvilket giver større anvendelighed til administration af forskellige processer og skabeloner.
Der er andre typer udbydere af udviklerplatform, som kan håndtere forskellige opgaver via skabeloner. I forbindelse med handlinger til kildekontrol kan udbydere hjælpe med at administrere Git-opgaver, f.eks. oprettelse af lagre, indsendelse af pullanmodninger eller andre Git-handlinger uden at være afhængige af generelle arbejdsprocesprogrammer. Klargøring af infrastruktur kan strømlines via dedikerede udbydere, f.eks. Azure Deployment Environments eller Terraform Cloud, med fokus på Infrastruktur som kode (IaC) med sikkerhed og effektivitet. Programstrukturudbydere, f.eks. Azure Developer CLI, understøtter oprettelse af programkildetræer og pushning af dem til kildelagre, hvilket giver fleksibilitet til forskellige økosystemer. Manuelle processer, f.eks. generering af pullanmodninger eller automatisering af arbejdsprocesser for ikke-udviklere, kan også administreres via skabelonbaserede udbydere, hvilket giver mulighed for gradvis automatisering. I disse eksempler fremhæves det, hvordan udvidelse og tilpasningsmulighed i udbydere af udviklerplatform kan forbedre automatiseringsfunktionerne over tid.