Tillämpa programvarutekniksystem

Att förbättra utvecklarens självbetjäning bör vara ett av de första problemen du tar itu med i din plattformsutvecklingsresa.

Ett av de enklaste sätten att börja aktivera automatiserade självbetjäningsupplevelser är att återanvända dina befintliga tekniska system. Dessa system är inte bara bekanta för dig och dina interna kunder, utan de kan möjliggöra en bred bredd av automatiseringsscenarier även om den första användarupplevelsen inte är vacker.

Den här artikeln innehåller tips för hur du använder dina tekniska system för att hantera en bredare uppsättning självbetjäningsscenarier och information om hur du kapslar in metodtips i mallar som hjälper dig att börja rätt och hålla dig rätt.

Utvärdera dina grundläggande DevOps- och DevSecOps-metoder

Tekniska system är en viktig aspekt av din interna utvecklarplattform. Interna utvecklarplattformar utgår från grundprinciperna i DevOps och DevSecOps för att minska den kognitiva belastningen för alla inblandade.

DevOps kombinerar utveckling och åtgärder för att förena människor, processer och teknik inom programplanering, utveckling, leverans och drift. Det är avsett att förbättra samarbetet mellan historiskt siloade roller som utveckling, IT-drift, kvalitetsutveckling och säkerhet. Du upprättar en kontinuerlig loop mellan utveckling, distribution, övervakning, observation och feedback. DevSecOps integreras i den här processen genom kontinuerliga säkerhetsrutiner under hela programutvecklingsprocessen.

Följande avsnitt fokuserar på förbättringar som är mer direkt kopplade till plattformsutvecklingsrörelsen: asfalterade sökvägar, automatiserad infrastrukturetablering (förutom programdistribution), konfiguration av kodningsmiljön, tillsammans med självbetjäningsetablering och konfiguration av verktyg, teamtillgångar och tjänster som inte är direkt en del av programutvecklingsloopen.

Skapa dina önskade asfalterade vägar

Om du redan har flera uppsättningar verktyg som utgör dina tekniska system är ett tidigt beslut att fatta om du vill konsolidera dem som en del av dina inledande plattformstekniska insatser eller om du kommer att stödja en konstellation av olika verktyg från början. Att definiera en uppsättning asfalterade vägar i den här konstellationen av verktyg är mest effektivt och ger en ökad flexibilitetsnivå.

När du börjar gå över till ett produkttänk bör du tänka på de tekniska systemen inom dessa banade vägar som består av verktyg som hanteras centralt som en tjänst till utvecklingsteam. Enskilda team eller avdelningar inom din organisation kan sedan avvika men förväntas hantera, underhålla och betala för sina verktyg separat samtidigt som de fortfarande följer eventuella efterlevnadskrav. Detta ger ett sätt att mata in nya verktyg i ekosystemet utan avbrott eftersom du kan utvärdera allt som avviker för eventuell inkludering i en asfalterad väg över tid. Som en plattformsutvecklingsledare uttryckte det:

Du kan fortfarande göra din egen grej, men gör det i en riktning vi rör oss mot… du kan ändra vad du vill, men detta blir ditt ansvar. Du äger ändringarna – du äger de vassa knivarna. - Mark, plattformsingenjör, stort europeiskt multinationellt detaljhandelsföretag

Med tanke på att ett viktigt mål för plattformsteknik är att övergå till ett produkttänk där du ger värde till dina interna kunder, fungerar den här konstellationsmetoden vanligtvis bättre än ett top-down-mandat. När du upprättar och förfinar dina asfalterade vägar kan du genom att lämna viss flexibilitet ge teamen möjlighet att ge synpunkter och uppfylla alla verkligt unika krav för ett visst program utan att påverka andra delar av organisationen. Detta leder till en uppsättning helt asfalterade, gyllene vägar, medan andra bara delvis asfalteras. I fall där det inte finns några unika krav gör den extra arbetsutveckling som teamen tar på sig naturligt att de vill flytta till en väg som stöds över tid.

Om du föredrar en konsolideringsstrategi kan det vara mer arbete att migrera befintliga program än du förväntar dig, så för att börja vill du förmodligen först fokusera på att börja på rätt sätt i det här utrymmet och sedan på nya projekt. Detta erbjuder din första asfalterade väg, medan allt annat finns där som oinvigd. Utvecklingsteam på den oupptäckta vägen kan sedan överväga att flytta när din nya asfalterade väg visar sitt värde för organisationen. Då kan du köra en justeringskampanj för att få alla till önskat läge genom dubbelriktad kommunikation eftersom utvecklingsgrupperna ser detta som en fördel snarare än en belastning. Under kampanjen kan plattformsteknikteam fokusera på att hjälpa team att migrera, medan utvecklingsteamen ger feedback om hur de utstakade vägarna kan förbättras.

Oavsett, undvik att kräva användning av dina asfalterade vägar. Det mest effektiva sättet att lansera asfalterade vägar är att betona vad team får ut av dem snarare än genom tvingad användning. Eftersom din interna utvecklarplattform fokuserar på att göra exakt samma team nöjda, tar budget- och tid-till-värde-trycket på enskilda ledare hand om resten. Genomför rätt kampanjer och skapa sedan en plattform för tvåvägskommunikation för bästa sättet för de som befinner sig på en outnyttjad väg att övergå.

Använd verktyg för utvecklarautomatisering för att förbättra självbetjäning för dina asfalterade vägar

En del av att skapa din första asfalterade väg bör vara att etablera dina grundläggande automationsprodukter för utvecklare. Dessa är viktiga när du börjar tänka på att aktivera självbetjäningsfunktioner för utvecklare.

Aktivera automatisk etablering av programinfrastruktur under kontinuerlig leverans

Om de inte redan har implementerats pekar de problem som du identifierade under planeringen sannolikt på problem som kontinuerlig integrering (CI) och kontinuerlig leverans (CD) kan hjälpa till att lösa. Det finns produkter som GitHub Actions, Azure DevOps, Jenkins och pull-baserade GitOps-lösningar som Flux eller Argo CD i det här utrymmet. Du kan komma igång med de här ämnena i Resurscentret för Microsoft DevOps.

Även om du redan har implementerat ett sätt att kontinuerligt distribuera ditt program i befintlig infrastruktur bör du överväga att använda infrastruktur som kod (IaC) för att skapa eller uppdatera nödvändig programinfrastruktur som en del av din CD-pipeline.

Tänk dig till exempel följande illustrationer som visar två metoder som använder GitHub Actions för att uppdatera infrastrukturen och distribuera till Azure Kubernetes Service: en med push-baserade distributioner och en pull-baserad distribution (GitOps).

Det du väljer drivs av din befintliga IaC-kompetensuppsättning och informationen om din målprogramplattform. GitOps-metoden är nyare och är populär bland organisationer som använder Kubernetes som bas för sina program, medan den pull-baserade modellen för närvarande ger dig mest flexibilitet med tanke på antalet tillgängliga alternativ för den. Vi förväntar oss att de flesta organisationer använder en blandning av de två. Oavsett kan du lära dig mönster som gäller för ytterligare automatiseringsscenarier om du blir väl insatt i IaC-metoder.

Centralisera IaC i en katalog eller ett register för att skala och förbättra säkerheten

Om du vill hantera och skala IaC mellan program bör du publicera dina IaC-artefakter centralt för återanvändning. Du kan till exempel använda Terraform-moduler i ett register, Bicep-moduler, Radius-recept eller Helm-diagram som lagras i ett molnbaserat OCI Artifact-register som Azure Container Registry (ACR), DockerHub eller katalogen i Azure Deployment Environments (ADE). För GitOps och Kubernetes kan du med kluster-API (och implementeringar som CAPZ) hantera Kubernetes-arbetsbelastningskluster, medan anpassade resursdefinitioner som Azure Service Operator kan ge extra stöd för andra typer av Azure-resurser. Andra verktyg, såsom Crossplane, stöder resurser över flera molntjänster. Med dessa kan du använda centraliserade eller vanliga Helm-diagram i något som liknar ACR för en bredare uppsättning scenarier.

Att centralisera IaC förbättrar säkerheten genom att ge dig bättre kontroll över vem som kan göra uppdateringar eftersom de inte längre lagras med programkod. Det finns mindre risk för ett oavsiktligt avbrott orsakat av en ändring under en koduppdatering när experter, drifttekniker eller plattformstekniker gör nödvändiga ändringar. Utvecklare drar också nytta av dessa byggstenar eftersom de inte behöver skapa fullständiga IaC-mallar själva och automatiskt dra nytta av kodade metodtips.

Vilket IaC-format du väljer beror på din befintliga kompetensuppsättning, vilken kontrollnivå du behöver och vilken appmodell du använder. Till exempel är Azure Container Apps (ACA) och det senaste experimentella Radius OSS-inkubationsprojektet mer åsiktsbaserade än att använda Kubernetes direkt, men också effektivisera utvecklarupplevelsen. Mer information om för- och nackdelar med olika modeller finns i Beskriv molntjänsttyper. Oavsett så har det betydande fördelar att referera till centraliserad och hanterad IaC i stället för att ha fullständiga definitioner i källträdet.

Lagra alla nödvändiga etableringsidentiteter eller hemligheter utan att utvecklare kan nå dem direkt, som del av de grundläggande byggstenarna för styrning. Tänk dig till exempel den här bilden av rollavgränsningen som du kan uppnå med hjälp av Azure Deployment Environments (ADE).

Här utvecklar plattformstekniker och andra specialister IaC och andra mallar och placerar dem i en katalog. Operationer kan sedan lägga till hanterade identiteter och prenumerationer efter miljötyp och tilldela utvecklare och andra användare som får använda dem för konfiguration.

Utvecklare eller din CI/CD-pipeline kan sedan använda Azure CLI eller Azure Developer CLI för att etablera förkonfigurerad och kontrollerad infrastruktur utan att ens ha åtkomst till den underliggande prenumerationen eller identiteterna som krävs för att göra det. Oavsett om du använder något som liknar ADE eller inte kan ditt system för kontinuerlig leverans hjälpa dig att uppdatera infrastrukturen på ett säkert sätt genom att separera hemligheter och köpa IaC-innehåll från platser som utvecklare inte kan komma åt eller ändra på egen hand.

Aktivera självbetjäning i scenarier utöver kontinuerlig leverans av program

Ci- och CD-begrepp är knutna till programutveckling, men många av de saker som dina interna kunder vill etablera är inte direkt kopplade till ett visst program. Detta kan vara delad infrastruktur, skapa en lagringsplats, etableringsverktyg med mera.

För att förstå var detta kan hjälpa bör du tänka på var du för närvarande har manuella processer eller servicedeskbaserade processer. Tänk på de här frågorna för var och en:

• Hur ofta sker den här processen?
• Är processen långsam, felbenägen eller kräver betydande arbete för att uppnå?
• Är dessa processer manuella på grund av ett nödvändigt godkännandesteg eller helt enkelt brist på automatisering?
• Är godkännare bekanta med källkontrollsystem och processer för pull-begäranden?
• Vilka är granskningskraven för processerna? Skiljer sig dessa från källkontrollsystemets granskningskrav?
• Finns det processer som du kan börja med som är lägre risk innan du går vidare till mer komplexa?

Identifiera frekventa, snabba eller felbenägna processer som potentiella mål för att automatisera först.

Använda allt som kodmönster

En av de fina sakerna med Git utöver dess allestädes närvarande är att det är avsett att vara en säker, granskningsbar informationskälla. Utöver incheckningshistoriken och åtkomstkontrollerna är begrepp som pull requests och grenskydd ett sätt att upprätta specifika granskare, en konversationshistorik och/eller automatiserade kontroller som måste klaras innan de slås samman till huvudgrenen. I kombination med flexibla aktivitetsmotorer som de som finns i CI/CD-system har du ett säkert automationsramverk.

Tanken bakom allt som kod är att du kan omvandla nästan vad som helst till en fil på en säker Git-lagringsplats. Olika verktyg eller agenter som är anslutna till lagringsplatsen kan sedan läsa innehållet. Att behandla allt som kod underlättar repeterbarheten genom templatering och förenklar utvecklarens självbetjäning. Nu ska vi gå igenom flera exempel på hur detta kan fungera.

Tillämpa IaC-mönster på valfri infrastruktur

Även om IaC blev populärt för att hjälpa till att automatisera programleveransen utökas mönstret till alla infrastrukturer, verktyg eller tjänster som du kanske vill etablera och konfigurera, inte bara de som är knutna till ett specifikt program. Till exempel delade Kubernetes-kluster med Flux installerat, etablering av något som DataDog som används av flera team och program, eller till och med konfigurera dina favorit samarbetsverktyg.

Det sätt som detta fungerar på är att du har en separat, skyddad centraliserad lagringsplats som rymmer en serie filer som representerar vad som ska etableras och konfigureras (i det här fallet allt från Bicep eller Terraform till Helm-diagram och andra Kubernetes-inbyggda format). Ett driftteam eller en annan uppsättning administratörer äger lagringsplatsen, och utvecklare (eller system) kan skicka pull-begäranden (PR). När dessa PR:er har sammanfogats i huvudgrenen av dessa administratörer kan samma CI/CD-verktyg som används under programutvecklingen börja bearbeta ändringarna. Tänk på följande bild som visar GitHub Actions, IaC och distributionsidentiteter som finns i Azure Deployment Environments:

Om du redan använder en GitOps-metod för programdistribution kan du även återanvända dessa verktyg. Genom att kombinera verktyg som Flux och Azure Service Operator kan du expandera utanför Kubernetes:

I båda fallen har du en fullständigt hanterad, reproducerbar och granskningsbar informationskälla, även om det som produceras inte är för ett program. Precis som med programutveckling lagras alla hemligheter eller hanterade identiteter som du behöver i pipeline-/arbetsflödesmotorn eller i de inbyggda funktionerna i en etableringstjänst.

Eftersom de personer som gör pr inte har direkt åtkomst till dessa hemligheter, ger det ett sätt för utvecklare att på ett säkert sätt initiera åtgärder som de inte har direkt behörighet att göra själva. På så sätt kan du följa principen om lägsta behörighet samtidigt som du ger utvecklare ett självbetjäningsalternativ.

Spåra tillhandahållen infrastruktur

När du börjar skala den här metoden bör du tänka på hur du vill spåra infrastrukturen som etablerades. Git-lagringsplatsen är en sanningskälla för konfigurationen, men du får inte de specifika URI:erna och tillståndsinformationen om det du skapade. Men genom att följa en metod för allt som kod får du en informationskälla att utnyttja för att syntetisera en inventering av etablerad infrastruktur. Din leverantör kan också vara en bra källa till den här informationen som du kan använda. Azure Deployment Environments innehåller till exempel miljöspårningsfunktioner som utvecklare har insyn i.

Mer information om spårning mellan olika datakällor finns i Designa en självbetjäningsgrund för utvecklare.

Tillämpa säkerheten som kod och princip som kodmönster

Etableringsinfrastrukturen är användbar, men det är lika viktigt att se till att dessa miljöer är säkra och generellt följer organisationens principer. Detta ledde till uppkomsten av konceptet policy som kod. Här kan konfigurationsfiler i en källkontrolllagringsplats användas för att göra saker som genomsökning av enhetssäkerhet eller tillämpa infrastrukturprinciper.

Många olika produkter och projekt med öppen källkod har antagit den här metoden, bland annat Azure Policy, Open Policy Agent, GitHub Advanced Security och GitHub CODEOWNERS. När du väljer programinfrastruktur, tjänster eller verktyg bör du utvärdera hur väl de stöder dessa mönster. Mer information om hur du förfinar ditt program och styrning finns i Förfina programplattformen.

Använda allt som kod för dina egna scenarier

Allt som kod utökar dessa mönster till en mängd olika automatiserings- och konfigurationsuppgifter utöver IaC. Det kan inte bara stödja att skapa eller konfigurera någon typ av infrastruktur, utan även uppdatera data eller utlösa arbetsflöden i alla underordnade system.

PR blir en bra grundläggande självbetjäningsanvändarupplevelse för olika processer, särskilt när du kommer igång. Processerna får naturligtvis de säkerhets-, gransknings- och återställningsfördelar som Git själv tillhandahåller och de system som ingår kan också ändras över tid utan att påverka användarupplevelsen.

Teams som kod

Ett exempel på hur du tillämpar allt som kod på dina egna scenarier är teamen som kodmönster. Organisationer tillämpar det här mönstret för att standardisera teammedlemskap och i vissa fall utvecklarverktyg/tjänsträttigheter i en mängd olika system. Det här mönstret eliminerar manuella onboarding- och offboarding-servicedeskprocesser som drivs av behovet av att systemutvecklare och operatörer får åtkomst till sina egna grupperings-, användar- och åtkomstkoncept. Manuella servicedeskprocesser är en potentiell säkerhetsrisk eftersom det är möjligt att överetablera åtkomst. När du använder teamen som kodmönster kan kombinationen av Git och PR aktivera självbetjäning från en granskningsbar datakälla.

Ett exempel på en mogen, omfattande variant av det här mönstret finns i GitHubs blogginlägg om hur de hanterar rättigheter. GitHub har också öppen källkod för sin avancerade berättigandeimplementering som du kan prova eller använda. Även om blogginlägget beskriver samtliga anställdas rättigheter kan du tillämpa konceptet med team som kod på mer begränsade scenarier för utvecklingsteam. Dessa utvecklingsteam kanske inte är representerade i ett organisationsschema för anställda alls och omfattar proprietära verktyg eller tjänster som kan komplicera introduktion eller offboarding av teammedlemmar.

Här är en sammanfattning av en förenklad variant av den här idén som använder ett CI/CD-system och identitetsprovidergrupper för att samordna uppdateringar:

I det här exemplet:

• Varje system har konfigurerats för att använda din identitetsprovider (till exempel Microsoft Entra-ID) för enkel inloggning (SSO).
• Du använder identitetsprovidergrupper (till exempel Entra-grupper) mellan system för att hantera medlemskap efter roll för att minska komplexiteten och upprätthålla centraliserad granskning.

På en hög nivå fungerar det här mönstret så här:

• En central, låst Git-lagringsplats har en uppsättning (vanligtvis YAML)-filer i den som representerar varje abstrakt team, relaterat användarmedlemskap och användarroller. Ägare eller godkännare för teamändringar kan också sparas på samma plats (till exempel via CODEOWNERS). Referensen till en användare i dessa filer är identitetsprovidern, men den här lagringsplatsen fungerar som sanningskälla för dessa team (men inte användare).
• Alla uppdateringar av dessa filer görs via pull-begäranden. Detta kopplar konversationer och relaterade deltagare till en begäran i Git commit för revisionskontroll.
• Leads och enskilda användare kan göra PR för att lägga till eller ta bort medlemmar, och dev leads och andra roller kan skapa nya team med hjälp av PR:er och en ny teamfil från en mall.
• När en PR slås samman med huvudgrenen uppdaterar ett CI/CD-system som är kopplat till lagringsplatsen identitetsprovidersystemet och alla underordnade system efter behov.

Närmare bestämt CI/CD-systemet:

• Använder rätt API för identitetsprovidersystem för att skapa eller uppdatera en identitetsprovidergrupp per roll med exakt individerna i filen (inte mer, inte mindre).
• Använder API:er för varje nedströmssystem för att koppla systemgrupperingskonceptet till en identifierande providergrupper för varje roll (till exempel GitHub och Azure DevOps). Detta kan resultera i en en-till-många-relation mellan ditt team och det underordnade systemet för att representera en roll.
• (Valfritt) Använder API:er för varje nedströmssystem för att implementera behörighetslogik som är kopplad till systemets grupperingsmekanism.
• Använder ett API för att uppdatera ett låst datalager med resultaten (inklusive associera de underordnade systemteam-ID:n) som sedan kan användas för något av dina internt byggda system. Du kan också lagra associationer för olika systemrepresentationer av användar-ID:t för samma identitetsprovideranvändare/-konto här, om det behövs.

Om din organisation redan använder något i stil med Entra-berättigandehantering kanske du kan utelämna hantering av gruppmedlemskap från det här mönstret.

Dina behov och principer kan ändra detaljerna, men det allmänna mönstret kan anpassas till valfritt antal varianter. Hemligheter som krävs för att integrera med underordnade system bevaras antingen i CI/CD-systemet (till exempel i GitHub Actions eller Azure Pipelines) eller i något som liknar Azure Key Vault.

Använda manuella eller externt utlösta, parameteriserade arbetsflöden

Vissa av de självbetjäningsrelaterade problem som du identifierar kanske inte bidrar till att använda filer i Git. Eller så kan du ha ett användargränssnitt som du vill använda för att driva självbetjäningsupplevelsen.

Lyckligtvis har de flesta CI-system, inklusive GitHub Actions och Azure Pipelines, möjlighet att konfigurera ett arbetsflöde med indata som du sedan kan utlösa manuellt via deras UIs eller CLIs. Med tanke på att utvecklare och relaterade åtgärdsroller förmodligen redan är bekanta med dessa användarupplevelser kan manuella utlösare utöka allt som kodmönster för att aktivera automatisering för aktiviteter (eller jobb) som antingen inte har en naturlig filrepresentation eller bör vara helt automatiserade utan att kräva en PR-process.

Ditt CI-system kan göra att du kan välja att utlösa dessa arbetsflöden eller pipelines från dina egna användarupplevelser via ett API. För GitHub Actions är nyckeln till att få detta att fungera Actions REST API för att aktivera ett arbetsflödesdispatchevent som startar en arbetsflödeskörning. 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. Oavsett om det utlöses manuellt eller via ett API kan varje arbetsflöde stödja en uppsättning indata genom att lägga till en workflow_dispatch konfiguration i arbetsflödets YAML-fil. Det är till exempel så här portalverktyg som Backstage.io interagerar med GitHub Actions.

CI/CD-systemets arbetsflöde eller jobbsystem spårar utan tvekan aktiviteter, rapporterar tillbaka status och har detaljerade loggar som både utvecklare och driftteam kan använda för att se vad som gick fel. På så sätt har den några av samma säkerhets-, gransknings- och synlighetsfördelar som everything-as-code-mönster. En sak att tänka på är dock att alla åtgärder som utförs av dessa arbetsflöden eller pipelines uppfattas som en systemidentitet (till exempel service principal eller hanterad identitet i Microsoft Entra ID) av underordnade system.

Du får insyn i vem som initierar begäranden i ditt CI/CD-system, men du bör utvärdera om det är tillräckligt med information och se till att dina CI/CD-kvarhållningsinställningar uppfyller dina granskningskrav för fall när den här informationen är kritisk.

I andra fall kan de verktyg som du integrerar med ha egna spårningsmekanismer som du kan lita på. Dessa CI/CD-verktyg har nästan alltid flera meddelandemekanismer tillgängliga, till exempel att använda en Microsoft Teams- eller Slack-kanal, vilket gör att alla som skickar en begäran kan få statusuppdateringar, och kanalen tillhandahåller en informell dokumentation av vad som hände. Samma arbetsflödesmotorer är ofta redan utformade för att integreras med driftverktyg för att ytterligare utöka nyttan av dessa mönster.

Sammanfattningsvis kan du implementera viss automatisering med hjälp av filer som lagras på en lagringsplats för källkontroll tack vare flexibiliteten i CI/CD-verktyg och deras färdiga användarupplevelser. Information om hur interna utvecklarplattformar kan använda den här metoden som utgångspunkt utan att kompromissa med mer avancerade funktioner över tid finns i Utforma en självbetjäningsgrund för utvecklare.

Automatisera konfigurationen av utvecklarkodningsmiljöer

Ett annat vanligt problem i tekniska system är initiering och normalisering av utvecklingsmiljöer. Här är några av de vanliga problem som du kan få höra om på det här området:

• I vissa fall kan det ta veckor för en utvecklare att komma åt sin första pull-begäran. Det här är ett problematiskt område när du överför utvecklare mellan funktionsteam och projekt ganska ofta (till exempel i matrisorganisationer), behöver rampa upp entreprenörer eller är i ett team som är i en anställningsfas.
• Inkonsekvens mellan utvecklare och med dina CI-system kan leda till frekventa "det fungerar på min dator"-problem även för erfarna teammedlemmar.
• Experimentering och uppgradering av ramverk, körningstider och annan programvara kan också bryta befintliga utvecklarmiljöer och leda till förlorad tid för att försöka ta reda på exakt vad som gick fel.
• För utvecklingsledare kan kodgranskningar sakta ner utvecklingen eftersom de kan kräva en konfigurationsändring för test och återställning när granskningen är avslutad.
• Teammedlemmar och operatörer måste också ägna tid åt att öka relaterade roller bortom utveckling (operatörer, QA, företag, sponsorer) för att hjälpa till att testa, se framsteg, träna affärsroller och evangelisera det arbete som teamet utför.

En del av dina asfalterade vägar

För att lösa dessa problem bör du överväga installationen av specifika verktyg och hjälpmedel som en del av dina väldefinierade arbetssätt. Installation av skriptutvecklare kan vara till hjälp och du kan återanvända samma skript i DIN CI-miljö. Överväg dock att stödja containerbaserade eller virtualiserade utvecklingsmiljöer på grund av de fördelar de kan ge. Dessa kodningsmiljöer kan konfigureras i förväg enligt organisationens eller projektets specifikationer.

Ersättning av arbetsstation och inriktning på Windows

Om du antingen riktar in dig på Windows eller vill göra fullständig arbetsstationsvirtualisering (klientverktyg och inställningar för värdoperativsystem utöver projektspecifika inställningar) ger virtuella datorer vanligtvis de bästa funktionerna. Dessa miljöer kan vara användbara för allt från Windows-klientutveckling till Windows-tjänst eller hantering och underhåll av .NET-webbprogram för fullständigt ramverk.

Tillvägagångssätt	Examples
Använda molnbaserade virtuella datorer	Microsoft Dev Box är ett fullständigt virtualiseringsalternativ för Windows-arbetsstationer med inbyggd integrering av programvara för skrivbordshantering.
Använda lokala virtuella datorer	Hashicorp Vagrant är ett bra alternativ och du kan använda HashiCorp Packer för att skapa VM-avbildningar för både den och Dev Box.

Virtualisering av arbetsytor och inriktat mot Linux

Om du riktar in dig på Linux bör du överväga ett virtualiseringsalternativ för arbetsytor. De här alternativen fokuserar mindre på att ersätta utvecklarskrivbordet och mer på projekt- eller programspecifika arbetsytor.

Tillvägagångssätt	Examples
Använda molnbaserade containrar	GitHub Codespaces är en molnbaserad miljö för Dev Containers som stöder integrering med VS Code, JetBrains IntelliJ och terminalbaserade verktyg. Om den här eller en liknande tjänst inte uppfyller dina behov kan du använda VS Code:s SSH eller fjärrtunnlar med Dev Containers på virtuella Linux-datorer. Det tunnelbaserade alternativet som inte bara fungerar med klienten, utan även det webbaserade vscode.dev.
Använda lokala containrar	Om du föredrar ett lokalt Dev Containers-alternativ i stället eller utöver ett moln som är värdbaserat har Dev Containers gediget stöd i VS Code, stöd i IntelliJ och andra verktyg och tjänster.
Använda molnbaserade virtuella datorer	Om du tycker att containrar är för begränsande kan du med SSH-stöd i verktyg som VS Code eller JetBrains-verktyg som IntelliJ ansluta direkt till virtuella Linux-datorer som du hanterar själv. VS Code har tunnelbaserat alternativ som fungerar även här.
Använda Windows-undersystemet för Linux	Om utvecklarna endast använder Windows är Windows-undersystem för Linux (WSL) ett bra sätt för utvecklare att rikta in sig på Linux lokalt. Du kan exportera en WSL-distribution för ditt team och dela den med allt som har konfigurerats. För ett molnalternativ kan molnarbetsstationstjänster som Microsoft Dev Box också dra nytta av WSL för att rikta Linux-utveckling.

Skapa starträtta programmallar som innehåller stay right-konfiguration

Det fantastiska med allt-som-kod-principen är att det kan hålla utvecklare på de asfalterade vägar du etablerade från början. Om detta är en utmaning för din organisation kan programmallar snabbt bli ett viktigt sätt att återanvända byggstenar för att skapa konsekvens, främja standardisering och kodifiera organisationens bästa praxis.

Till att börja med kan du använda något så enkelt som en GitHub-malllagringsplats, men om din organisation följer ett monorepomönster kan det vara mindre effektivt. Du kan också skapa mallar som hjälper dig att konfigurera något som inte är direkt relaterat till ett programkällaträd. I stället kan du använda en mallmotor som cookiecutter, Yeoman eller något liknande Azure Developer CLI (azd) som, förutom att redigera och förenkla CI/CD-installationen, även tillhandahåller en bekväm uppsättning utvecklarkommandon. Eftersom Azure Developer CLI kan användas för att driva miljökonfigurationen i alla scenarier integreras den med Azure Deployment Environments för att ge förbättrad säkerhet, integrerad IaC, miljöspårning, separation av problem och förenklad CD-installation.

När du har en uppsättning mallar kan utvecklingsledare använda dessa kommandoradsverktyg eller andra integrerade användarupplevelser för att strukturera innehållet för sina applikationer. Men eftersom utvecklare kanske inte har behörighet att skapa lagringsplatser eller annat innehåll från dina mallar är detta också en annan möjlighet att använda manuellt utlösta, parameteriserade arbetsflöden eller pipelines. Du kan konfigurera indata så att ditt CI/CD-system skapar allt från en lagringsplats till infrastruktur åt dem.

Att hålla sig rätt och få rätt

För att hjälpa till att skala bör dessa programmallar referera till centraliserade byggstenar där det är möjligt (till exempel IaC-mallar eller till och med CI/CD-arbetsflöden och pipelines). Att faktiskt behandla dessa centraliserade byggstenar som sin egen form av mönster för rätt start kan vara en effektiv strategi för att lösa några av de problem du har identifierat.

Var och en av dessa enskilda mallar kan tillämpas inte bara på nya program, utan även befintliga som du tänker uppdatera som en del av en get right-kampanj för att distribuera uppdaterade eller förbättrade riktlinjer. Ännu bättre är att den här centraliseringen hjälper dig att behålla både nya och befintliga program så att du kan utveckla eller utöka dina metodtips över tid.

Mallens innehåll

Vi rekommenderar att du överväger följande områden när du skapar mallar.

Area	Detaljer
Tillräcklig exempelkällkod för att driva appmönster, SDK:er och verktygsanvändning	Inkludera kod och konfiguration för att styra utvecklare mot rekommenderade språk, appmodeller och tjänster, API:er, SDK:er och arkitekturmönster. Se till att inkludera kod för distribuerad spårning, loggning och observerbarhet med valfria verktyg.
Skapa och distribuera skript	Ge utvecklare ett vanligt sätt att aktivera en build och en lokal/sandbox-miljö. Inkludera felsökningskonfiguration i IDE/redigeraren för valfritt verktyg för att använda dem. Detta är ett viktigt sätt att undvika underhållshuvudvärk och förhindra att CI/CD är osynkroniserat. Om din mallmotor är åsiktsbaserad som Azure Developer CLI kanske det redan finns kommandon som du bara kan använda.
Konfiguration för CI/CD	Ange arbetsflöden/pipelines för att skapa och distribuera program baserat på dina rekommendationer. Dra nytta av centraliserade, återanvändbara eller mallade arbetsflöden/pipelines för att hålla dem up-to-date. I själva verket kan dessa återanvändbara arbetsflöden/pipelines fungera som egna mallar. Se till att överväga ett alternativ för att manuellt utlösa dessa arbetsflöden.
Infrastruktur som kodtillgångar	Ange rekommenderade IaC-konfigurationer, inklusive referenser till centralt hanterade moduler eller katalogobjekt för att säkerställa att alla infrastrukturinstallationer följer bästa praxis från start. Dessa referenser kan också hjälpa teamen att hålla sig rätt när tiden går. Kombinerat med arbetsflöden/pipelines kan du även inkludera IaC eller EaC för att tillhandahålla nästan vad som helst.
Säkerhet och princip som kodtillgångar	DevSecOps-rörelsen flyttade säkerhetskonfigurationen till kod, vilket är bra för mallar. Vissa principer som kodartefakter kan också tillämpas på programnivå. Inkludera allt från filer som CODEOWNERS till genomsökningskonfiguration som dependabot.yaml i GitHub Advanced Security. Ange schemalagda arbetsflöden/pipelinekörningar för genomsökningar med något som liknar Defender för molnet tillsammans med miljötestkörningar. Detta är viktigt för säkerhet i leveranskedjan och se till att ta hänsyn till containeravbildningar utöver programpaket och kod. De här stegen hjälper utvecklingsteamen att hålla sig på rätt spår.
Observerbarhet, övervakning och loggning	En del av att aktivera självbetjäning är att ge enkel insyn i program när de har distribuerats. Utöver körningsinfrastrukturen måste du inkludera installation för observerbarhet och övervakning. I de flesta fall finns det en IaC-aspekt vid konfigurering (till exempel agentdistribution, installering, instrumentation) medan det i andra kan vara en annan typ av konfigurationsartefakt (till exempel övervakningspaneler för Azure Application Insights). Se slutligen till att inkludera kodexempelkod för distribuerad spårning, loggning och observerbarhet med hjälp av valfria verktyg.
Konfiguration av kodningsmiljö	Inkludera konfigurationsfiler för kodning av linters, formatters, redigerare och IDE:er. Inkludera installationsskript tillsammans med virtualiseringsfiler för arbetsytor eller arbetsstationer som devcontainer.json, devbox.yaml, utvecklarfokuserade Dockerfiles, Docker Compose-filer eller Vagrantfiles.
Testkonfiguration	Ange konfigurationsfiler för både enhet och mer djupgående testning med hjälp av dina önskade tjänster som Microsoft Playwright Testing för användargränssnitt eller Azure App Testing.
Konfiguration av samarbetsverktyg	Om ditt system för hantering av problem och källkontroll stöder uppgifts-/problem-/PR-mallar som kod, inkluderar du även dessa. I de fall där mer konfiguration krävs kan du ange ett arbetsflöde/en pipeline som uppdaterar dina system med hjälp av ett tillgängligt CLI eller API. På så sätt kan du också konfigurera andra samarbetsverktyg som Microsoft Teams eller Slack.

Relaterat innehåll

• Microsofts DevOps-resurscenter
• Containers säkra leveranskedjeframtagning
• CI/CD-baslinjearkitektur med Azure Pipelines
• Förfina programplattformen