Tillämpa programvarutekniksystem

När du förstår de problem som du vill ta itu med först i din plattformsteknikresa kan det bli bättre att förbättra utvecklarens självbetjäning överst i listan. Ett av de enklaste sätten att börja aktivera automatiserade självbetjäningsupplevelser är att återanvända dina befintliga tekniska system. Dessa system kommer inte bara att vara bekanta för dig och dina interna kunder, utan de kan möjliggöra en stor mängd automatiseringsscenarier även om den ursprungliga användarupplevelsen inte är vacker.

Den här artikeln innehåller några tips för att tillämpa dina tekniska system för att hantera ett bredare utbud av självbetjäningsscenarier och hur du kan kapsla 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. Men om du inte redan har några system som riktar in sig på åtminstone några av de viktigaste klientorganisationer i DevOps och DevSecOps, kommer de problem som du identifierar sannolikt att berätta för dig att börja där. Interna utvecklarplattformar byggs upp från dem för att minska den kognitiva belastningen för alla inblandade.

DevOps kombinerar utveckling och drift 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-lager i den här loopen med kontinuerliga säkerhetsmetoder under programutvecklingsprocessen.

Microsofts DevOps-resurscenter är ett bra ställe att leta efter råd om vilka typer av processer och system du behöver, så vi går inte igenom dessa närmare i det här avsnittet. Dessa blir viktiga ingredienser när du går vidare. Glöm inte att ta med de senaste DevSecOps-ämnena som säkerhet i containerförsörjningskedjan i dina planer.

Mer information om kontinuerlig feedback finns i mått att överväga. Du kan också lära dig mer om verktyg för användning inom områdena observerbarhet, övervakning och kontinuerlig feedback i Förfina din programplattform.

I resten av den här artikeln fokuserar vi på förbättringar som mer direkt tillskrevs plattformens tekniska rörelse: banade vägar, automatiserad etablering av infrastruktur (förutom programdistribution), kodning av miljökonfiguration, tillsammans med självbetjäningsetablering och konfiguration av verktyg, teamtillgångar och tjänster som inte är direkt en del av programutvecklingsloopen.

Upprätta önskade banade vägar

Om du redan har flera uppsättningar verktyg som utgör dina tekniska system måste du fatta ett tidigt beslut om du vill ta ett pass för att konsolidera dem som en del av dina inledande plattformstekniker eller om du kommer att stödja en konstellation av olika verktyg från början. I de flesta fall är det mest effektivt att definiera en uppsättning asfalterade vägar i den här konstellationen av verktyg och ger ökad flexibilitet.

När du börjar gå över till ett produkttänk kan du betrakta tekniksystemen inom dessa banade vägar som att de består av verktyg som hanteras centralt som en tjänst för 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 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 från eventuell inkludering i en asfalterad väg över tid. Som en plattformstekniker uttryckte det:

Du kan fortfarande göra din egen sak, men gör det i en riktning vi ska... du kan ändra vad du vill, men detta blir ditt ansvar. Du äger ändringarna – du äger de vassa knivarna. - Mark, plattformstekniksledare, Large European Multinational Retail Company

Med tanke på att ett viktigt mål för plattformsteknik är att övergå till produkttänk där du ger värde till dina interna kunder, fungerar den här konstellationsmetoden vanligtvis bättre än ett uppifrån och ned-mandat. När du upprättar och förfinar dina banade vägar kan team med viss flexibilitet tillhandahålla indata och uppfylla alla verkligt unika krav för ett visst program utan att påverka andra i organisationen. Detta leder till en uppsättning fullt asfalterade, gyllene stigar, medan andra bara delvis asfalteras. I de fall där det inte finns några unika krav kommer de extra arbetsutvecklingsteamen naturligtvis att vilja flytta till en sökväg som stöds över tid.

Om du föredrar en konsolideringsstrategi bör du tänka på att migrering av befintliga program kan vara mer arbete än du förväntar dig, så för att börja vill du förmodligen fokusera på starträtt aspekten av det här utrymmet och fokusera på nya projekt. Detta ger dig din första asfalterade väg, medan allt befintligt är osparat. Utvecklingsteam på den osparade vägen kommer sedan att överväga att flytta när din nya asfalterade väg visar dess värde för organisationen. Då kan du köra en get right-kampanj för att få alla på önskat tillstånd genom dubbelriktad kommunikation eftersom utvecklingsteamen ser detta som en fördel snarare än en skatt. Under kampanjen kan plattformstekniker fokusera på att hjälpa team att migrera, medan utvecklingsteamen ger feedback om hur de banade sökvägarna kan förbättras.

Oavsett, försök att undvika att föreskriva användningen av dina asfalterade vägar. Det mest effektiva sättet att distribuera dem är att betona vad team får ut av dem snarare än genom framtvingad implementering. Eftersom din interna utvecklarplattform fokuserar på att göra dessa exakt samma team glada, tenderar budget- och tid till värde-trycket på enskilda ledare att ta hand om resten. Få rätt kampanjer och ge sedan en väg för dubbelriktade konversationer på det bästa sättet för dem på en osparad väg att växla över.

Använd automatiseringsverktyg för utvecklare för att förbättra självbetjäning för dina banade vägar

En del av att skapa din första stenlagda 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 kommer de problem som du identifierade under planeringen sannolikt att peka på problem som kontinuerlig integrering (CI) och kontinuerlig leverans (CD) kan hjälpa dig att lösa. Produkter som GitHub Actions, Azure DevOps, Jenkins och pull-baserade GitOps-lösningar som Flux eller Argo CD finns i det här utrymmet. Du kan komma igång med de här ämnena i Resurscenter för Microsoft DevOps.

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

Tänk dig till exempel de här illustrationerna 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).

Mer information om varje metod finns i CI/CD för AKS-appar med GitHub Actions och Gitflow.

Som du väljer drivs ofta av din befintliga IaC-kompetensuppsättning och information om målprogramplattformen. 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 kommer att använda en blandning av de två. Oavsett så 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 :et (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 som crossplane-stödresurser över flera moln. Med dessa kan du använda centraliserade eller vanliga Helm-diagram i något som liknar ACR för en bredare uppsättning scenarier.

Centralisering av 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 en oavsiktlig avbrott som orsakas av en oavsiktlig ändring under en koduppdatering när experter, driftstekniker eller plattformstekniker gör nödvändiga ändringar. Utvecklare kan också dra 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. Utbildningsmodulen Beskriv molntjänsttyper kan hjälpa dig att förstå för- och nackdelarna med olika modeller. 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.

Bevara alla nödvändiga etableringsidentiteter eller hemligheter på ett sätt som utvecklare inte kan komma åt dem direkt i de grundläggande byggstenarna för styrning. Tänk dig till exempel den här bilden av rollseparationen 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. Åtgärder 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 etablering.

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 i stil med 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.

Om du vill veta var det kan vara till hjälp kan 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 att uppnå?
• Är dessa processer manuella på grund av ett obligatoriskt godkännandesteg eller helt enkelt brist på automatisering?
• Om en godkännare behövs, är de 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 processer, stora ansträngningar eller felbenägna processer som potentiella mål för att automatisera först. Härnäst går vi igenom några enkla sätt att få detta att hända.

Använd allt som kodmönster

En av de trevliga sakerna med git förutom dess allmänt förekommande är att det är avsett att vara en säker, granskningsbar informationskälla. Utöver incheckningshistoriken och åtkomstkontrollerna är begrepp som pull-begäranden och grenskydd ett sätt att upprätta specifika granskare, en konversationshistorik och eller automatiserade kontroller som måste skickas innan de sammanfogas till huvudgrenen. I kombination med flexibla uppgiftsmotorer som de som finns i CI/CD-system har du ett säkert automatiseringsramverk.

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 mallning och förenklar självbetjäning för utvecklare. Nu ska vi gå igenom flera exempel på hur detta kan fungera.

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

Även om IaC har blivit mer 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 visst program. Till exempel delade K8:or med kluster med Flux installerat, etablering av något som DataDog som används av flera team och program eller till och med konfigurerar dina favorit samarbetsverktyg.

Det här fungerar på så sätt att du har en separat, skyddad centraliserad lagringsplats som innehåller en serie filer som representerar vad som ska etableras och konfigureras (i det här fallet allt från Bicep, Terraform till Helm-diagram och andra kubernetes-inbyggda format). Ett driftsteam eller en annan uppsättning administratörer äger lagringsplatsen, och utvecklare (eller system) kan skicka pull-begäranden. När dessa pull-begäranden har slagits samman i huvudgrenen av dessa administratörer kan samma CI/CD-verktyg som används under programutvecklingen börja bearbeta ändringarna. Tänk på den här bilden som använder GitHub Actions och 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 skapas inte är för ett program. Precis som med programutveckling kan alla hemligheter eller hanterade identiteter som du behöver lagras i pipeline-/arbetsflödesmotorn eller i de inbyggda funktionerna i en etableringstjänst.

Eftersom de personer som gör pr-begärandena inte har direkt åtkomst till dessa hemligheter, ger det utvecklare ett sätt 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 utvecklarna får ett självbetjäningsalternativ.

Spåra etablerad 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 anger inte de specifika URI:erna och tillståndsinformationen om det du har skapat. Men genom att följa en allt som kod-metod får du en informationskälla att utnyttja för att syntetisera en inventering av etablerad infrastruktur. Etableringsverktyget kan också vara en bra källa till den här informationen som du kan utnyttja. Azure-distributionsmiljöer innehåller till exempel miljöspårningsfunktioner som utvecklare har insyn i.

Mer information om spårning över olika datakällor finns i Design a developer self-service foundation (Utforma 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 följer organisationens principer. Detta har lett till att begreppet "policy som kod" har ökat. Här kan konfigurationsfiler i en lagringsplats för källkontroll användas för att göra saker som att genomsöka säkerheten eller tillämpa infrastrukturprinciper.

Många olika produkter och öppen källkod projekt har implementerat stöd för 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 användas för att skapa eller konfigurera någon typ av infrastruktur, utan även att uppdatera data eller utlösa arbetsflöden i alla underordnade system.

Pr blir en bra självbetjäningsanvändarupplevelse för olika processer – särskilt när du kommer igång. Processerna får naturligtvis de fördelar med säkerhet, granskning och återställning som git tillhandahåller, och de system som berörs 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 använder det här mönstret för att standardisera teammedlemskap och, i vissa fall, rättigheter för utvecklarverktyg/tjänster i en mängd olika system. Det här mönstret eliminerar manuell registrering och avregistrering av 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 teamen används som kodmönster kan kombinationen av git- och pull-begäranden aktivera självbetjäning från en granskningsbar datakälla.

Ett exempel på en mogen och 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 all-up medarbetares rättigheter, kan du använda teamen som kodkoncept för mer begränsade utvecklingsteamscenarier. Dessa utvecklingsteam kanske inte är representerade i ett organisationsschema för anställda alls och omfattar upphovsrättsskyddade verktyg eller tjänster som kan komplicera registrering eller avregistrering 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 förutsätter vi att:

1. Varje system har konfigurerats för att använda din identitetsprovider (till exempel Microsoft Entra ID) för enkel inloggning (SSO).
2. 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:

1. En central, låst git-lagringsplats har en uppsättning (vanligtvis YAML)-filer som representerar varje abstrakt team, relaterat användarmedlemskap och användarroller. Ägare/godkännare för lagändringar kan också lagras 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).
2. Precis som i andra kodfall görs alla uppdateringar av dessa filer via pull-begäranden. Detta binder konversationer och relaterade deltagare på begäran till git-incheckning för granskning.
3. Leads och enskilda användare kan göra pr för att lägga till/ta bort personer, och utvecklingsleas och andra roller kan skapa nya team med pr som med en ny teamfil från en mall.
4. När en pull-begäran slås samman till main uppdaterar ett CI/CD-system som är knutet till lagringsplatsen identitetsprovidersystemet och alla underordnade system efter behov.

Mer specifikt: CI/CD-systemet:

5. 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).
6. Använder API:er för varje nedströmssystem för att koppla systemgrupperingskonceptet till en identifierande providergrupper för varje roll (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.
7. Du kan också använda API:er för varje nedströmssystem för att implementera behörighetslogik som är kopplad till systemets grupperingsmekanism.
8. Använder ett API för att uppdatera ett låst datalager med resultatet (inklusive att associera 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:er för samma identitetsprovideranvändare/-konto här om det behövs.

Observera att om din organisation redan använder något i stil med Berättigandehantering i Entra kanske du inte kan hantera 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 underhålls antingen i CI/CD-systemet (till exempel i GitHub Actions, Azure Pipelines) eller i något som liknar Azure Key Vault.

Använda manuella eller externt utlösta, parametriserade 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.

Som tur är 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 CLI:er. Eftersom 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.

I själva verket kan ditt CI-system göra det möjligt för dig att välja att utlösa dessa arbetsflöden/pipelines från dina egna användarupplevelser via ett API. För GitHub Actions är nyckeln till att göra det här arbetet rest-API:et Actions för att utlösa en arbetsflödessändningshändelse för att utlösa en arbetsflödeskörning. 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. Oavsett om de utlöses manuellt eller via ett API kan varje arbetsflöde ha stöd för en uppsättning indata genom att lägga till en workflow_dispatch konfiguration i yaml-filen för arbetsflödet. Det är till exempel så här portalverktyg som Backstage.io interagerar med GitHub Actions.

Ci/CD-systemets arbetsflöde/jobbsystem spårar utan tvekan aktiviteter, rapporterar tillbaka status och har detaljerade loggar som både utvecklare och driftsteam kan använda för att se vad som gick fel. På så sätt har den samma säkerhets-, gransknings- och synlighetsfördelar som allt som kodmönster. En sak att tänka på är dock att alla åtgärder som utförs av dessa arbetsflöden/pipelines ser ut som en systemidentitet (till exempel tjänstens huvudnamn eller hanterad identitet i Microsoft Entra ID) till 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 kvarhållningsinställningarna för CI/CD uppfyller granskningskraven 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 till exempel nästan alltid flera tillgängliga meddelandemekanismer som att använda en Microsoft Teams - eller Slack-kanal , vilket gör att du kan låta vem som helst skicka en begäran om att få statusuppdateringar och kanalen tillhandahåller en informell post om vad som hände. Samma arbetsflödesmotorer är ofta redan utformade för att integreras med åtgärdsverktyg för att ytterligare utöka nyttan av dessa mönster.

Sammanfattningsvis kan du implementera en 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 installationen av kodningsmiljöer för utvecklare

Ett annat vanligt problem som du kan identifiera som dina tekniska system kan hjälpa dig med är utvecklarens kodning av miljöstövlar och normalisering. Här är några av de vanliga problem som du kan höra om i 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 starta 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 "it works on my machine"-problem även för erfarna teammedlemmar.
• Experimentering och uppgradering av ramverk, körningstider och annan programvara kan också bryta befintliga utvecklarmiljöer och resultera i förlorad tid för att ta reda på exakt vad som gick fel.
• För utvecklingsleas kan kodgranskningar sakta ned utvecklingen eftersom de kan kräva en konfigurationsändring för att testa och ångra dem när granskningen är klar.
• Teammedlemmar och operatörer måste också ägna tid åt att öka relaterade roller utöver utveckling (operatörer, QA, företag, sponsorer) för att testa, se framsteg, träna affärsroller och evangelisera det arbete som teamet utför.

En del av dina asfalterade stigar

För att lösa dessa problem bör du tänka på konfiguration av specifika verktyg och verktyg som en del av dina väldefinierade banade vägar. Skriptkonfiguration av utvecklardatorer 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 mål för Windows

Om du antingen riktar in dig på Windows eller vill göra fullständig virtualisering av arbetsstationer (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änsten eller för att hantera och underhålla .NET-webbprogram med fullständigt ramverk.

Strategi	Exempel
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 linux-mål

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

Strategi	Exempel
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 Codes SSH - eller fjärrtunnlar med Dev Containers på fjärranslutna 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 molnbaserat alternativ 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 tunnelbaserade alternativ som fungerar även här.
Använd Windows-undersystem för Linux	Om dina utvecklare 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 in sig på Linux-utveckling.

Skapa starträtta programmallar som innehåller förblir rätt konfiguration

Det fantastiska med allt som kodmönster är att det kan hålla utvecklare på de banade vägar som du har etablerat från början. Om det här är en utmaning för din organisation kan programmallar snabbt bli ett viktigt sätt att återanvända byggstenar för att främja 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 kanske också vill skapa mallar som hjälper dig att konfigurera något som inte är direkt relaterat till ett programkällans träd. I stället kan du använda en mallmotor som cookiecutter, Yeoman eller något liknande Azure Developer CLI (azd) som, förutom mallning och förenklad CI/CD-installation, även ger en praktisk 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 bättre säkerhet, integrerad IaC, miljöspårning, separation av problem och förenklad CD-installation.

När du har en uppsättning mallar kan utvecklingsleads använda dessa kommandoradsverktyg eller andra integrerade användarupplevelser för att autogenerera sitt innehåll för sina program. 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, parametriserade arbetsflöden/pipelines. Du kan konfigurera indata så att CI/CD-systemet skapar allt från en lagringsplats till infrastruktur för deras räkning.

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

Men 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/pipelines). I själva verket kan du upptäcka att behandla dessa centraliserade byggstenar som sin egen form av start höger mallar är en effektiv strategi för att lösa några av de problem som du har identifierat.

Var och en av dessa enskilda mallar kan tillämpas inte bara på nya program, utan även på 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.

Mallinnehåll

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

Området	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 hjälp av valfria verktyg.
Skapa och distribuera skript	Ge utvecklare ett vanligt sätt att utlösa en version och en lokal/sandbox-distribution. Inkludera felsökningskonfiguration i IDE/editor för de verktyg som du väljer att använda dem. Detta är ett viktigt sätt att undvika underhållshuvudvärk och förhindra att CI/CD är osynkroniserat. Om mallmotorn visas 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 uppdaterade. I själva verket kan dessa återanvändbara arbetsflöden/pipelines starta rätt mallar på egen hand. Tänk på ett alternativ för att utlösa dessa arbetsflöden manuellt.
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 allt eftersom tiden går. I kombination med arbetsflöden/pipelines kan du även inkludera IaC eller EaC för att etablera nästan vad som helst.
Säkerhet och princip som kodtillgångar	DevSecOps-rörelsen har också flyttat 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ökning av konfiguration som dependabot.yaml i GitHub Advanced Security. Ange schemalagda arbetsflöden/pipelinekörningar för genomsökningar som liknar Defender för molnet tillsammans med miljötestkörningar. Detta är särskilt 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 rätt.
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 att konfigurera (till exempel agentdistribution, instrumentation) medan det i andra kan vara en annan typ av konfigurationskodartefakt (till exempel övervakning av instrumentpaneler 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, formaterare, redigerare och IDE:er. Inkludera installationsskript tillsammans med virtualiseringsfiler för arbetsytor eller arbetsstationer som devcontainer.json, devbox.yaml, dockerfiles som fokuseras på utvecklare, Docker Compose-filer eller Vagrantfiles.
Testkonfiguration	Ange konfigurationsfiler för både enhet och mer djupgående testning med hjälp av önskade tjänster som Microsoft Playwright Testing för användargränssnittet eller Azure Load Testing.
Konfiguration av samarbetsverktyg	Om ditt system för hantering av problem och källkontroll stöder uppgifts-/ärende-/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.

Förfina programplattformen