Förstå miljöer

  • 8 minuter

Med distributionspipelines kan du automatisera stegen i distributionsprocessen. Ofta måste du köra stegen i flera separata miljöer. I ditt leksaksföretag vill du granska ändringarna i koden innan du distribuerar ändringarna till produktionsmiljön.

I den här lektionen får du lära dig mer om hur miljöer i Azure Pipelines hjälper dig att stödja ditt eget arbetsflöde.

Varför har du flera miljöer?

Distributionsprocesser gör ändringar i dina Azure-resurser, inklusive resurser som används. Att ändra resurser innebär en viss risk, eftersom de ändringar som du distribuerar kanske inte fungerar som förväntat. Du kanske till och med upptäcker att ändringarna bryter den aktuella konfigurationen.

För att minimera risken för problem är det bra att prova dina ändringar på ett säkert sätt innan du distribuerar dem till produktionsmiljön. Du kan till exempel distribuera ändringarna till en icke-produktionsmiljö.

Många organisationer konfigurerar flera icke-produktionsmiljöer där de gradvis distribuerar sina ändringar innan de släpps till produktion. Varje icke-produktionsmiljö har ett specifikt syfte och har ofta specifika kvalitetsgrindar som måste uppfyllas för att gå vidare till nästa miljö. Om något går fel, till exempel om ett test misslyckas, stoppas distributionen. När distributionen flyttas genom varje miljö växer ditt förtroende för ändringarna.

Vanliga miljöer är:

  • Utveckling: En utvecklingsmiljö används vanligtvis av utvecklare för att prova sina ändringar i och för att snabbt iterera sitt arbete.

    Utvecklingsmiljöer har ofta minimala kontroller så att teammedlemmar enkelt kan prova idéer. Du kan använda en utvecklingsmiljö för att testa en viss konfigurationsinställning för en resurs eller för att se hur du kan konfigurera en ny webbplats med en serverdelsdatabas på ett säkert sätt. Många av dessa ändringar och utvärderingsversioner kanske inte går framåt i distributionsprocessen, eftersom du eliminerar de idéer som inte lyckas.

    I vissa team kan du till och med konfigurera en separat utvecklingsmiljö för varje gruppmedlem så att de inte kommer i vägen för varandra när de arbetar med nya funktioner.

    Utvecklingsmiljöer kallas ibland även sandbox-miljöer .

  • Test: En testmiljö är utformad för att köra manuella eller automatiserade tester mot dina ändringar.

    Testmiljöer kan användas i en kontinuerlig integreringsprocess. När du har distribuerat en ändring till en testmiljö kan automatiserade tester köras mot den. Om alla automatiserade tester godkänns är ändringen säker för sammanslagning till huvudgrenen i projektet. Automatiserade tester söker vanligtvis efter kärnsystemfunktionerna, tillsammans med saker som principöverträdelser i de nyligen distribuerade resurserna.

    Du kan också skapa dedikerade testmiljöer för specifika typer av testning, till exempel prestanda- och säkerhetstestning.

  • Integrering: En integrationsmiljö kan hjälpa dig att testa alla integreringsplatser med andra system.

    Du kan simulera transaktioner från slutpunkt till slutpunkt i en integrationsmiljö. Dessa tester körs ofta automatiskt, men många organisationer utför också manuella tester mot den här miljön.

    Integrationsmiljöer kallas ibland även sit-miljöer (System Integration Test ).

  • Användargodkännandetest: En UAT-miljö (User Acceptance Test) används för manuell validering, vanligtvis av företagsintressenter snarare än utvecklare. I manuell validering går någon igenom lösningen och verifierar att den fungerar som förväntat och att den uppfyller de nödvändiga affärskraven. Den personen godkänner sedan ändringarna så att distributionen kan fortsätta.

  • Förproduktion: En förproduktionsmiljö är ofta en spegling av produktionsmiljön, med samma resurs-SKU:er och konfiguration. Den används som en sista kontroll för att kontrollera hur produktionsdistributionen kommer att bete sig under och efter att ändringen har tillämpats. Den kan också användas för att kontrollera om du kan förvänta dig någon stilleståndstid under produktionsdistributionen.

    Förproduktionsmiljöer kallas ibland även för mellanlagringsmiljöer .

  • Produktion: Produktionsmiljön är den som slutanvändarna av programmet använder. Det är din livemiljö som du vill skydda och hålla igång så mycket som möjligt.

    I vissa organisationer kan du ha flera produktionsmiljöer. Du kan till exempel ha produktionsmiljöer i olika geografiska regioner eller för att betjäna olika kundgrupper.

  • Demo: Ditt team kan också skapa demonstrationsmiljöer (demo) för att visa programmet för slutanvändare, för användning i träning eller för säljteam för att visa vissa funktioner för potentiella kunder. Du kan till och med ha flera demomiljöer som har olika syften. En demomiljö är ofta en nedbantad replik av din produktionsmiljö med falska kunddata.

Miljöer i din organisation

Du kan se varianter av dessa miljöer. Vissa organisationer använder bara några få miljöer, och vissa använder många fler. Antalet och typen av miljöer som du använder beror på vilken lösning du distribuerar, storleken på det team som skapar lösningen och arbetsbelastningens betydelse.

Ibland tar en enskild miljö rollen för flera av de miljöer som angavs tidigare. Andra gånger kan du ha en komplex pipeline som distribueras till flera miljöer, vissa parallellt och vissa i följd. Vissa organisationer tar till och med bort eller avetablerar miljöer automatiskt när de inte längre används och distribuerar dem sedan igen när de behövs i framtiden.

Oavsett vad din organisation väljer som sin lista över miljöer är målet att förbättra ditt förtroende för en ändring när den fortskrider via distributionspipelinen. När en ändring inte uppfyller dina kvalitetskrav vill du kunna stoppa distributionen av ändringen till efterföljande miljöer i kedjan.

I ditt leksaksföretag bestämmer du dig för att börja med en grundläggande uppsättning miljöer för din webbplats. Förutom produktionsmiljön skapar du en icke-produktionsmiljö med namnet Test:

Diagram som visar två miljöer: test och produktion.

Du uppdaterar pipelinen för att distribuera Bicep-koden till testmiljön och köra några grundläggande tester mot den. Om den här åtgärden lyckas distribueras koden till din produktionsmiljö.

Pipelinemiljöer

Azure Pipelines har också begreppet miljö. Du skapar en Azure Pipelines-miljö som representerar den miljö som du har i Azure. När du definierar din pipeline i en YAML-fil länkar du dina distributionsjobb till en specifik miljö. Med hjälp av miljöer får du några andra funktioner i pipelinen.

Kontroller och godkännanden

En miljö i Azure DevOps kan ha kontroller och godkännanden konfigurerade. Varje gång miljön används i ett jobb i din pipeline ser Azure DevOps till att dessa kontroller och godkännanden lyckas innan jobbet börjar köras.

Du kan till exempel konfigurera manuella godkännanden i produktionsmiljön. Innan en produktionsdistribution startar får den utsedda godkännaren ett e-postmeddelande. Den personen kan manuellt kontrollera att dina principer och procedurer uppfylls innan distributionen börjar. Godkännaren kan till exempel kontrollera att allt fungerar som förväntat i förproduktionsmiljön innan de godkänner distributionen.

Dessutom kan du köra en automatisk kontroll för att granska loggarna och felfrekvensen i förproduktionsmiljön efter den senaste distributionen. Om kontrollen bekräftar att antalet fel inte har ökat avsevärt kan distributionen fortsätta.

Distributionshistorik

Azure Pipelines spårar historiken för distributionerna till en miljö. Den här historiken ger dig ett enkelt sätt att spåra vad som händer i miljön över tid. Du kan till och med spåra en distribution till en specifik funktionsbegäran i dina Azure Boards-arbetsobjekt eller till en incheckning på lagringsplatsen. Den här funktionen kan vara användbar om du har problem med en distribution och behöver identifiera den ändring som ledde till problemet.

Säkerhet

Du kan använda andra säkerhetskontroller i miljöer. Du kan begränsa de pipelines som tillåts använda en viss miljö. Eller förhindra att någon oavsiktligt skapar en sekundär pipeline som interagerar med din produktionsmiljö.

Du kan också använda användarbehörigheter för att styra de användare som kan hantera miljöer. Specifika behörigheter kan göra det möjligt för användare att skapa nya miljöer, ändra miljöer och visa miljöer och historik för distributioner till dem.

Kommentar

När din pipeline refererar till en miljö som inte finns ännu skapar Azure Pipelines den automatiskt åt dig. Den här funktionen kan påverka säkerheten för ditt Azure DevOps-projekt eftersom du automatiskt får administratörsbehörighet till miljön. Det är bäst att skapa en miljö själv via Azure DevOps-webbgränssnittet, så att du har fullständig kontroll över dess säkerhet och inte av misstag får behörigheter som du inte behöver.

I din distributionspipelinedefinition skapar du en deployment egenskap för att ange ett distributionsjobb och anger namnet på den miljö som jobbet distribuerar till:

- stage: DeployTest
  displayName: Deploy (Test Environment)
  jobs:
  - deployment: DeployWebsite
    environment: Test
    strategy:
      runOnce:
        deploy:
          steps:
            - checkout: self

I exemplet är jobbet med namnet DeployWebsite länkat till Test miljön.

Dricks

Jobb har också andra egenskaper, inklusive distributionsstrategin, som ligger utanför omfånget för den här modulen. Vi länkar till mer information i sammanfattningsenheten.

Miljöer och tjänstanslutningar

När du använder flera miljöer bör du göra varje miljö oberoende av de andra. Din utvecklingsmiljös webbplats bör till exempel inte kunna komma åt en databas i produktionsmiljön.

Samma princip gäller även för distributionspipelinen. Den tjänstanslutning som du använder för att distribuera till utvecklingsmiljön bör inte kunna komma åt produktionsmiljön. Genom att följa den här principen läggs ytterligare ett skyddslager till för att säkerställa att dina icke-produktionsdistributioner inte påverkar produktionsmiljön.

Du bör skapa separata tjänstanslutningar för varje miljö. Varje tjänstanslutning bör använda sitt eget dedikerade tjänsthuvudnamn, med specifika behörigheter för att endast distribuera till prenumerationen och resursgruppen som används av den miljön:

Diagram som visar en tjänstanslutning, tjänstens huvudnamn och Azure-resursgrupp för icke-produktion och en annan uppsättning för produktion.

Viktigt!

Använd ett separat tjänsthuvudnamn och en tjänstanslutning för varje miljö som du planerar att distribuera till. Ge tjänstens huvudnamn de minsta behörigheter som krävs för att distribuera till dess miljö, och inga andra.

Det är också en bra idé att separera dina miljöer i Azure. Du bör åtminstone skapa en separat resursgrupp för varje miljö. I många situationer är det bättre att skapa separata Azure-prenumerationer för varje miljö. Sedan kan du skapa flera resursgrupper i varje miljös prenumeration.

Tillämpa Azure-rolltilldelningar så att användare och tjänstens huvudnamn bara kan komma åt de miljöer som de behöver åtkomst till. Och var noga med att begränsa åtkomsten till din produktionsmiljö till en liten uppsättning personer och distributionstjänstens huvudnamn för den miljön.