Förstå miljöer

• 8 minuter

Med distributionsarbetsflöden 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 GitHub Actions hjälper dig att stödja din egen process.

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 minimerar risken genom att 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 ett komplext arbetsflöde 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 genom ditt distributionsarbetsflöde. 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:

Du uppdaterar arbetsflödet 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 kan du sedan distribuera till din produktionsmiljö.

Arbetsflödesmiljöer

GitHub Actions har också begreppet miljö. Du skapar en GitHub Actions-miljö som representerar den miljö som du har i Azure. När du definierar arbetsflödet i en YAML-fil kan du länka jobb till en specifik miljö. Med hjälp av miljöer får du ytterligare funktioner i arbetsflödet.

Skyddsregler

En miljö i GitHub Actions kan ha konfigurerade skyddsregler. Varje gång miljön används i ett jobb i arbetsflödet ser GitHub Actions till att dessa regler uppfylls innan jobbet börjar köras.

Du kan till exempel konfigurera manuella granskningar i produktionsmiljön. Innan en produktionsdistribution startar får den utsedda granskaren ett meddelande. 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 bekräfta den gren som ändringen kommer från. Om ändringen inte finns på huvudgrenen kan du konfigurera GitHub för att förhindra att den distribueras till produktionsmiljön.

Hemligheter

Med GitHub Actions kan du lagra hemligheter som bara kan användas med en specifik miljö. Du får lära dig mer om hantering av hemligheter senare i den här modulen.

Distributionshistorik

GitHub Actions 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 även spåra en distribution 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.

Skapa miljöer

Du kan skapa en miljö med hjälp av GitHub-webbgränssnittet.

När arbetsflödet refererar till en miljö som inte finns skapar GitHub Actions det automatiskt åt dig. Den här funktionen kan påverka säkerheten för din GitHub-lagringsplats eftersom den nya miljön inte har några konfigurerade skyddsregler. Det är bäst att skapa en miljö själv via GitHub-webbgränssnittet, så att du har fullständig kontroll över dess säkerhet.

Länka ett distributionsjobb till en miljö

I definitionen för distributionsarbetsflödet kan du referera till en miljö med hjälp environment av egenskapen:

jobs:
  deploy:
    environment: Test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

I det här exemplet är jobbet med namnet deploy länkat till Test miljön.

Miljöer och anslutningar till Azure

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 distributionsarbetsflödet. Du bör skapa separata arbetsbelastningsidentiteter för varje miljö. Genom att följa den här metoden läggs ytterligare ett skyddslager till för att säkerställa att dina icke-produktionsdistributioner inte påverkar produktionsmiljön.

Arbetsbelastningsidentiteter bör tilldelas specifika behörigheter för att endast distribuera till den prenumeration och resursgrupp som används av den miljön:

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 arbetsbelastningsidentiteter endast 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 distributionens arbetsbelastningsidentitet för den miljön.

Federerade autentiseringsuppgifter för miljöer

När din arbetsbelastningsidentitet ansluter till Azure från ditt distributionsarbetsflöde använder den en federerad autentiseringsuppgift för att autentisera sig på ett säkert sätt utan hemligheter eller nycklar. I tidigare moduler i den här utbildningsvägen gav dina federerade autentiseringsuppgifter åtkomst till dina distributionsarbetsflöden när de distribuerades från huvudgrenen på git-lagringsplatsen.

När du distribuerar till en miljö i arbetsflödet måste du använda en federerad autentiseringsuppgift som är begränsad till den miljön.

I den här modulen innehåller arbetsflödet flera jobb, varav många ansluter och distribuerar till Azure. Vissa av jobben använder miljöer, och andra inte. Därför skapar du två federerade autentiseringsuppgifter för var och en av dina arbetsbelastningsidentiteter: en som är begränsad till miljön och en som är begränsad till huvudgrenen .