Förhandsgranska och godkänn distributionen

5 minuter

Nu har du lärt dig om pipelinesteg och hur du kan lägga till en pipelinefas för att verifiera din Bicep-kod. Nästa steg för att skapa förtroende för distributionen är att lägga till ytterligare en fas för att kontrollera exakt vad distributionen kommer att ändra.

I den här lektionen får du lära dig mer om att använda kommandot what-if i en pipeline. Du får också lära dig mer om att lägga till godkännanden så att du kan verifiera kommandots utdata manuellt innan distributionen körs.

Konsekvensåtgärden

En Bicep-fil beskriver tillståndet som du vill att Azure-miljön ska vara i i slutet av en distribution. När du skickar en distribution ändrar Azure Resource Manager din Azure-miljö så att den matchar det tillstånd som beskrivs i Bicep-filen.

En distribution kan leda till att nya resurser distribueras till din miljö eller att befintliga resurser uppdateras. När du kör en distribution i fullständigt läge kan det även leda till att befintliga resurser tas bort.

När resurser skapas, uppdateras eller tas bort finns det en risk att saker och ting kan ändras på ett sätt som du inte förväntade dig. Det är en bra idé att lägga till ett extra steg för att kontrollera vilka resurser som ska skapas, uppdateras och tas bort. Den här verifieringen lägger till värde i automatiseringsprocessen. När du distribuerar till en produktionsmiljö är det viktigt att bekräfta eventuella ändringar i din miljö.

Resource Manager tillhandahåller konsekvensåtgärden som du kan köra på Bicep-filen i pipelinesteget:

Diagram över en pipeline som innehåller lint-, validerings- och förhandsversionssteg. Förhandsgranskningssteget kör en konsekvensåtgärd mot Azure.

Du kan använda az deployment group what-if Azure CLI-kommandot inifrån pipelinedefinitionen för att köra konsekvenssteget:

stages:

- stage: Preview
  jobs: 
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

Dricks

I den här modulen använder vi Azure CLI för att köra konsekvensåtgärden. Om du skapar en egen PowerShell-baserad pipeline kan du använda cmdleten New-AzResourceGroupDeployment med växeln -Whatif eller använda cmdleten Get-AzResourceGroupDeploymentWhatIfResult .

Konsekvensåtgärden gör inga ändringar i din miljö. I stället beskrivs de resurser som skapas eller tas bort, vilka resursegenskaper som ska uppdateras och vilka resurser som ska tas bort.

What-if visar ibland att en resurs ändras när det faktiskt inte sker någon ändring. Den här feedbacken kallas brus. Vi arbetar med att minska dessa problem, men vi behöver din hjälp med att rapportera dessa problem.

När du ser utdata från konsekvensåtgärden kan du avgöra om du vill fortsätta med distributionen. Det här steget innebär vanligtvis att en människa granskar utdata från konsekvenskommandot och sedan fattar ett beslut om huruvida de identifierade ändringarna är rimliga. Om en mänsklig granskare beslutar att ändringarna är rimliga kan de godkänna pipelinekörningen manuellt.

Mer information om kommandot what-if finns i Microsoft Learn-modulen Förhandsgranska Azure-distributionsändringar med hjälp av what-if.

Miljöer

I Azure Pipelines representerar en miljö den plats där din lösning distribueras. Miljöer tillhandahåller funktioner som hjälper dig när du arbetar med komplexa distributioner. I en framtida modul lär du dig mer om miljöer och deras funktioner. För tillfället fokuserar vi på deras möjlighet att lägga till manuella godkännanden i pipelinen.

Som du redan vet använder du jobb för att definiera en sekvens med steg i en pipelinefas. När du inkluderar miljöer i pipelinen måste du använda en särskild typ av jobb som kallas för ett distributionsjobb. Ett distributionsjobb liknar ett normalt jobb, men det ger några extra funktioner. Den här funktionen omfattar att definiera den miljö som distributionsjobbet använder:

variables:
  - name: deploymentDefaultLocation
    value: westus3

stages:

- stage: Preview
  jobs:
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

- stage: Deploy
  jobs:
    - deployment: Deploy
      environment: MyAzureEnvironment
      strategy:
        runOnce:
          deploy:
            steps:
            - checkout: self

            - task: AzureResourceManagerTemplateDeployment@3
              name: Deploy
              displayName: Deploy to Azure
              inputs:
                connectedServiceName: 'MyServiceConnection'
                location: $(deploymentDefaultLocation)
                resourceGroupName: $(ResourceGroupName)
                csmFile: deploy/main.bicep

Observera att det i YAML-definitionen för ett distributionsjobb finns några viktiga skillnader från ett normalt jobb:

I stället för att börja med ordet jobdefinieras ett distributionsjobb som deployment.
Nyckelordet environment anger namnet på den miljö som ska riktas. I föregående exempel spåras distributionen mot en miljö med namnet MyAzureEnvironment.
Nyckelordet strategy anger hur Azure Pipelines kör distributionsstegen. Distributionsstrategier stöder komplexa distributionsprocesser, särskilt där du har flera produktionsmiljöer. I den här modulen använder vi distributionsstrategin runOnce . Den här strategin fungerar på samma sätt som andra jobb som du redan är van vid.

Stegkontroller och godkännanden

När du har skapat en miljö kan du definiera kontroller. Kontroller används för att verifiera villkor som måste uppfyllas innan en pipeline kan använda miljön. Ett godkännande är en typ av kontroll som kräver att en människa ger ett manuellt godkännande.

Kontroller definieras i miljön, inte pipelinen. Författare av YAML-pipelinefilen kan inte ta bort eller lägga till dessa kontroller och godkännanden. Endast administratörer i en miljö kan hantera kontroller och godkännanden på den.

I många organisationer är ägaren av en miljö i Azure Pipelines den person som ansvarar för miljön som den distribuerar till. Kontroller och godkännanden hjälper till att säkerställa att rätt personer deltar i distributionsprocessen.

Hur fungerar kontroller och godkännanden?

Kontroller och godkännanden utvärderas precis innan en pipelinefas börjar. När Azure Pipelines är på väg att köra en pipelinefas tittar den på alla pipelineresurser som används i fasen, inklusive miljöer. Miljöer kan ha kontroller som måste uppfyllas.

Ett godkännande är en typ av kontroll. När du konfigurerar en godkännandekontroll tilldelar du en eller flera användare som behöver godkänna fortsättningen av din pipeline.

Azure Pipelines tillhandahåller även andra typer av kontroller. Du kan till exempel anropa ett API för att köra viss anpassad logik, styra kontorstiderna under vilken en fas kan köras och till och med fråga Azure Monitor för att säkerställa att en distribution har lyckats. Vi diskuterar endast godkännandekontroller i den här modulen, men vi tillhandahåller länkar till mer information om kontroller i sammanfattningen.

Kommentar

Agentpooler och tjänstanslutningar kan också ha kontroller konfigurerade på dem. Du kan också använda ett särskilt steg som kallas för en manuell godkännandeaktivitet. Men i den här modulen fokuserar vi på miljöer och de kontroller som är associerade med dem.

När pipelinen börjar och når ett steg som kräver en godkännandekontroll pausas pipelinekörningen. Alla användare som har utsetts till godkännare skickas ett meddelande i Azure DevOps och via e-post.

Godkännare kan inspektera pipelineloggarna, till exempel de ändringar som konsekvensåtgärden identifierar. Baserat på den här informationen godkänner eller avböjer de sedan ändringen. Om de godkänner ändringen återupptas pipelinen. Om de avböjer, eller om de inte svarar inom en konfigurerbar tidsgräns, misslyckas fasen.

Diagram över en pipeline som innehåller lint-, validerings-, förhandsversions- och distributionssteg med en godkännandekontroll före distributionsfasen.

Vikten av god praxis

Med miljöfunktionen i Azure Pipelines kan du länka dina distributioner till en miljö och sedan ärver distributionen de kontroller och godkännanden som definierats av miljöägaren. Det finns dock inget som kräver att nya pipelines använder miljöer.

Det är viktigt att du och din organisation upprättar bra metoder för att granska dina pipelinedefinitioner. Ett exempel är att konfigurera lagringsplatsen så att den kräver granskningar av pull-begäranden om ändringar i huvudgrenen med hjälp av principer för grenskydd. Du får lära dig mer om det här konceptet i en framtida modul.

Du kan också lägga till kontroller och godkännanden till tjänstanslutningar som säkerställer att godkännande erhålls innan en distribution kan använda autentiseringsuppgifterna för tjänstens huvudnamn. Godkännandena skulle dock också påverka din pipelines möjlighet att köra förhandsvalidering och konsekvensåtgärden, eftersom de också kräver en tjänstanslutning.