Forstå miljøer

  • 8 minutter

Med udrulningsarbejdsprocesser kan du automatisere trinnene i installationsprocessen. Du skal ofte køre trinnene i flere separate miljøer. I dit legetøjsfirma skal du gennemse ændringerne i din kode, før du udruller ændringerne i dit produktionsmiljø.

I dette undermodul får du mere at vide om, hvordan miljøer i GitHub-handlinger hjælper dig med at understøtte din egen proces.

Hvorfor har du flere miljøer?

Udrulningsprocesserne ændrer dine Azure-ressourcer, herunder de ressourcer, der er i brug. Ændring af ressourcer udgør en risiko, fordi de ændringer, du udruller, muligvis ikke fungerer som forventet. Du opdager måske endda, at ændringerne ødelægger den aktuelle konfiguration.

Hvis du vil minimere risikoen for problemer, er det en god idé at afprøve dine ændringer på en sikker måde, før du udruller dem i dit produktionsmiljø. Du minimerer risikoen ved at udrulle ændringerne i et ikke-produktionsmiljø.

Mange organisationer konfigurerer flere ikke-produktionsmiljøer, hvor de gradvist udruller deres ændringer, før de frigives til produktion. Hvert ikke-produktionsmiljø tjener et bestemt formål og har ofte specifikke kvalitetsporte, der skal opfyldes for at fortsætte til det næste miljø. Hvis noget går galt, f.eks. en testfejl, stopper udrulningen. I takt med at udrulningen bevæger sig gennem hvert miljø, vokser din tillid til ændringerne.

Almindelige miljøer omfatter:

  • Udvikling: Et udviklingsmiljø bruges typisk af udviklere til at prøve deres ændringer i og til hurtigt at gentage deres arbejde.

    Udviklingsmiljøer har ofte minimale kontrolelementer, så teammedlemmer nemt kan afprøve idéer. Du kan bruge et udviklingsmiljø til at teste en bestemt konfigurationsindstilling for en ressource eller til at se, hvordan du kan konfigurere et nyt websted med en back end-database på en sikker måde. Mange af disse ændringer og prøveversioner går muligvis ikke videre i udrulningsprocessen, fordi du fjerner de idéer, der ikke lykkes.

    I nogle teams kan du endda konfigurere et separat udviklingsmiljø for hvert teammedlem, så de ikke kommer i vejen for hinanden, mens de arbejder på nye funktioner.

    Udviklingsmiljøer kaldes også sandkasse- miljøer.

  • Test: Et testmiljø er designet til at køre manuelle eller automatiserede test i forhold til dine ændringer.

    Testmiljøer kan bruges i en kontinuerlig integrationsproces. Når du har implementeret en ændring i et testmiljø, kan automatiserede test køres i forhold til det. Hvis alle de automatiserede test består, er ændringen sikker at flette ind i projektets hovedgren. Automatiserede test kontrollerer normalt, om systemets kernefunktionalitet er korrekt, sammen med ting som politikovertrædelser i de nyligt udrullede ressourcer.

    Du kan også oprette dedikerede testmiljøer til bestemte testtyper, f.eks. ydeevne- og sikkerhedstest.

  • Integration: Et integrationsmiljø kan hjælpe dig med at teste integrationspunkter med andre systemer.

    Du kan simulere komplette transaktioner i et integrationsmiljø. Disse test kører ofte automatisk, men mange organisationer udfører også manuel test i forhold til dette miljø.

    Integrationsmiljøer kaldes også SIT-miljøer (System Integration Test).

  • Test af brugeraccept: Et UAT-miljø (User Acceptance Test) bruges til manuel validering, som regel af virksomhedsaktører i stedet for udviklere. I manuel validering gennemgår nogen løsningen og bekræfter, at den fungerer som forventet, og at den opfylder de nødvendige forretningsmæssige krav. Denne person godkender derefter ændringerne, så installationen kan fortsætte.

  • pre-production: Et præproduktionsmiljø er ofte en spejling af produktionsmiljøet med de samme ressource-SKU'er og konfiguration. Den bruges som en sidste kontrol til at kontrollere, hvordan udrulningen af produktionen fungerer under og efter ændringen er anvendt. Den kan også bruges til at kontrollere, om du kan forvente nedetid under udrulningen af produktionen.

    Præproduktionsmiljøer kaldes også nogle gange midlertidige miljøer.

  • Produktions: Dit produktionsmiljø er det, slutbrugerne af programmet bruger. Det er dit livemiljø, som du vil beskytte og holde op med at køre så meget som muligt.

    I nogle organisationer kan du have flere produktionsmiljøer. Du kan f.eks. have produktionsmiljøer i forskellige geografiske områder eller til at betjene forskellige grupper af kunder.

  • Demo-: Dit team kan også oprette demonstrationsmiljøer (demo) for at vise programmet til slutbrugere, til brug i oplæringen eller til salgsteams for at vise visse funktioner til potentielle kunder. Du kan endda have flere demomiljøer, der tjener forskellige formål. Et demomiljø er ofte en slanket replika af dit produktionsmiljø med falske kundedata.

Miljøer i din organisation

Du kan muligvis se variationer af disse miljøer. Nogle organisationer bruger kun nogle få miljøer, og nogle bruger mange flere. Antallet og typen af miljøer, du bruger, afhænger af den løsning, du udruller, størrelsen på det team, der bygger løsningen, og vigtigheden af arbejdsbelastningen.

Nogle gange har et enkelt miljø rollen som flere af de miljøer, der er angivet tidligere. Andre gange kan du have en kompleks arbejdsproces, der udrulles i flere miljøer, nogle parallelt og nogle i rækkefølge. Nogle organisationer sletter eller fjerner endda automatisk miljøer, når de ikke længere bruges, og geninstallerer dem, når der er behov for dem i fremtiden.

Uanset hvad din organisation vælger som sin liste over miljøer, er målet at forbedre din tillid til en ændring, efterhånden som den skrider frem via din udrulningsarbejdsproces. Når en ændring ikke opfylder dine kvalitetskrav, vil du kunne stoppe udrulningen af ændringen i efterfølgende miljøer i kæden.

I dit legetøjsfirma beslutter du dig for at starte med et grundlæggende sæt miljøer til dit websted. Ud over dit produktionsmiljø skal du oprette ét ikke-produktionsmiljø med navnet Test:

diagram, der viser to miljøer: test og produktion.

Du skal opdatere din arbejdsproces for at udrulle din Bicep-kode i dit testmiljø og køre nogle grundlæggende test mod den. Hvis denne indsats lykkes, kan du udrulle til dit produktionsmiljø.

Arbejdsprocesmiljøer

GitHub Actions har også begrebet et miljø. Du opretter et GitHub Actions-miljø for at repræsentere det miljø, du har i Azure. Når du definerer din arbejdsproces i en YAML-fil, kan du sammenkæde job med et bestemt miljø. Når du bruger miljøer, får du nogle ekstra funktioner i din arbejdsproces.

Beskyttelsesregler

Beskyttelsesregler kan være konfigureret for et miljø i GitHub-handlinger. Hver gang miljøet bruges i et job i din arbejdsproces, sikrer GitHub-handlinger, at disse regler overholdes, før jobbet begynder at køre.

Du kan f.eks. konfigurere manuelle korrekturer i dit produktionsmiljø. Før en udrulning af produktionen starter, modtager den udpegede korrekturlæser en meddelelse. Denne person kan manuelt bekræfte, at dine politikker og procedurer er opfyldt, før installationen starter. Godkenderen kan f.eks. kontrollere, at alt fungerer som forventet i præproduktionsmiljøet, før de godkender udrulningen.

Derudover kan du køre en automatiseret kontrol for at bekræfte den forgrening, som ændringen kommer fra. Hvis ændringen ikke findes på din primære forgrening, kan du konfigurere GitHub for at forhindre, at den udrulles i dit produktionsmiljø.

Hemmeligheder

Med GitHub-handlinger kan du gemme hemmeligheder, der kun kan bruges i et bestemt miljø. Du får mere at vide om administration af hemmelige oplysninger senere i dette modul.

Installationshistorik

GitHub Actions sporer historikken for udrulningerne i et miljø. Denne historik giver dig en nem måde at spore, hvad der sker i miljøet over tid. Det giver dig endda mulighed for at spore en installation til en bekræftelse i dit lager. Denne funktion kan være nyttig, hvis du har problemer med en installation og har brug for at identificere den ændring, der førte til problemet.

Opret miljøer

Du kan oprette et miljø ved hjælp af GitHub-webgrænsefladen.

Når din arbejdsproces refererer til et miljø, der ikke findes, opretter GitHub-handlinger det automatisk for dig. Denne funktion kan påvirke sikkerheden i dit GitHub-lager, fordi der ikke er konfigureret nogen beskyttelsesregler for det nye miljø. Det er bedst selv at oprette et miljø via GitHub-webgrænsefladen, så du har fuld kontrol over dets sikkerhed.

I definitionen af udrulningsarbejdsprocessen kan du referere til et miljø ved hjælp af egenskaben environment:

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

I dette eksempel er jobbet med navnet deploy knyttet til det Test miljø.

Miljøer og forbindelser til Azure

Når du bruger flere miljøer, skal du gøre hvert miljø uafhængigt af de andre. Dit udviklingsmiljøs websted bør f.eks. ikke kunne få adgang til en database i dit produktionsmiljø.

Det samme princip gælder også for udrulningsarbejdsprocessen. Du skal oprette separate arbejdsbelastningsidentiteter for hvert miljø. Efter denne fremgangsmåde tilføjes endnu et beskyttelseslag for at sikre, at dine ikke-produktionsudrulninger ikke påvirker dit produktionsmiljø.

Arbejdsbelastningsidentiteter skal tildeles specifikke tilladelser til kun at udrulle til det abonnement og den ressourcegruppe, der bruges af det pågældende miljø:

diagram, der viser en arbejdsbelastningsidentitet og en Azure-ressourcegruppe for ikke-produktion og et andet sæt til produktion.

Vigtig

Brug en separat arbejdsbelastningsidentitet for hvert miljø, du planlægger at udrulle til. Tildel arbejdsbelastnings-id'et de minimumtilladelser, der skal installeres i dets miljø, og ingen andre.

Det er også en god idé at adskille dine miljøer i Azure. Du skal som minimum oprette en separat ressourcegruppe for hvert miljø. I mange situationer er det bedre at oprette separate Azure-abonnementer for hvert miljø. Derefter kan du oprette flere ressourcegrupper i hvert miljøs abonnement.

Anvend Azure-rolletildelinger, så brugere og arbejdsbelastningsidentiteter kun kan få adgang til de miljøer, de har brug for at få adgang til. Og pas på at begrænse adgangen til dit produktionsmiljø til et lille sæt personer og id'et for udrulningsbelastningen for det pågældende miljø.

Legitimationsoplysninger i organisationsnetværk for miljøer

Når din arbejdsbelastningsidentitet opretter forbindelse til Azure fra din udrulningsarbejdsproces, bruger den en organisationslegitimationsoplysninger til sikkert at godkende sig selv uden hemmeligheder eller nøgler. I tidligere moduler i dette læringsforløb gav dine legitimationsoplysninger i organisationsnetværket adgang til dine udrulningsarbejdsprocesser, når de blev udrullet fra primære gren af dit Git-lager.

Når du udruller til et miljø i din arbejdsproces, skal du bruge et organisationsnetværkslegitimationsoplysninger, der er begrænset til det pågældende miljø.

I dette modul indeholder din arbejdsproces flere job, hvoraf mange opretter forbindelse og udruller til Azure. Nogle af jobbene bruger miljøer, og nogle gør det ikke. Så du opretter to legitimationsoplysninger i organisationsnetværket for hver af dine arbejdsbelastningsidentiteter: én, der er begrænset til miljøet, og én, der er begrænset til den primære forgrening.