Uw implementatie bekijken en goedkeuren

Voltooid

U hebt nu geleerd over pijplijnfasen en hoe u een pijplijnfase kunt toevoegen om uw Bicep-code te valideren. De volgende stap bij het opbouwen van vertrouwen met uw implementatie is het toevoegen van een andere fase om precies te controleren wat uw implementatie zal veranderen.

In deze les leert u hoe u de wat-als-opdracht in een pijplijn gebruikt. U leert ook hoe u goedkeuringen toevoegt, zodat u de mogelijkheid hebt om de uitvoer van de opdracht handmatig te controleren voordat de implementatie wordt uitgevoerd.

De wat-als-bewerking

Een Bicep-bestand beschrijft de status waarin u wilt dat uw Azure-omgeving zich aan het einde van een implementatie bevindt. Wanneer u een implementatie verzendt, wijzigt Azure Resource Manager uw Azure-omgeving zodat deze overeenkomt met de status die wordt beschreven in uw Bicep-bestand.

Een implementatie kan ertoe leiden dat nieuwe resources worden geïmplementeerd in uw omgeving of dat bestaande resources worden bijgewerkt. Wanneer u een implementatie uitvoert in de volledige modus, kan dit zelfs leiden tot het verwijderen van bestaande resources.

Wanneer resources worden gemaakt, bijgewerkt of verwijderd, bestaat het risico dat dingen kunnen veranderen op een manier die u niet had verwacht. Het is een goede gewoonte om een extra stap toe te voegen om te controleren welke resources worden gemaakt, bijgewerkt en verwijderd. Deze verificatie voegt waarde toe aan uw automatiseringsproces. Wanneer u implementeert in een productieomgeving, is het belangrijk dat u wijzigingen bevestigt die in uw omgeving plaatsvinden.

Resource Manager biedt de wat-als-bewerking, die u kunt uitvoeren op uw Bicep-bestand in uw pijplijnfase:

U kunt de az deployment group what-if Azure CLI-opdracht vanuit uw pijplijndefinitie gebruiken om de wat-als-stap uit te voeren:

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

Tip

In deze module gebruiken we de Azure CLI om de wat-als-bewerking uit te voeren. Als u uw eigen PowerShell-pijplijn bouwt, kunt u de New-AzResourceGroupDeployment cmdlet gebruiken met de -Whatif switch of u kunt de Get-AzResourceGroupDeploymentWhatIfResult cmdlet gebruiken.

Met de wat-als-bewerking worden geen wijzigingen aangebracht in uw omgeving. In plaats daarvan worden de resources beschreven die worden gemaakt of verwijderd, de resource-eigenschappen die worden bijgewerkt en de resources die worden verwijderd.

Wat-als laat soms zien dat een resource wordt gewijzigd wanneer er daadwerkelijk geen wijziging plaatsvindt. Deze feedback wordt ruis genoemd. We proberen deze problemen te verminderen, maar we hebben uw hulp nodig om deze problemen te melden.

Nadat u de uitvoer van de wat-als-bewerking hebt weergegeven, kunt u bepalen of u door wilt gaan naar de implementatie. Deze stap omvat doorgaans een mens die de uitvoer van de wat-als-opdracht controleert en vervolgens een beslissing neemt over of de geïdentificeerde wijzigingen redelijk zijn. Als een menselijke revisor besluit dat de wijzigingen redelijk zijn, kunnen ze de pijplijnuitvoering handmatig goedkeuren.

Voor meer informatie over de wat-als-opdracht raadpleegt u de microsoft Learn-module Preview van Azure-implementatiewijzigingen met behulp van wat-als.

Omgevingen

In Azure Pipelines vertegenwoordigt een omgeving de locatie waar uw oplossing wordt geïmplementeerd. Omgevingen bieden functies die u helpen bij het werken met complexe implementaties. In een toekomstige module leert u meer over omgevingen en hun functies. Voorlopig richten we ons op de mogelijkheid om handmatige goedkeuringen aan uw pijplijn toe te voegen.

Zoals u al weet, gebruikt u taken om een reeks stappen in een pijplijnfase te definiëren. Wanneer u omgevingen in uw pijplijn opneemt, moet u een speciaal type taak gebruiken dat een implementatietaak wordt genoemd. Een implementatietaak is vergelijkbaar met een normale taak, maar biedt extra functionaliteit. Deze functionaliteit omvat het definiëren van de omgeving die door de implementatietaak wordt gebruikt:

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

U ziet dat er in de YAML-definitie voor een implementatietaak enkele belangrijke verschillen zijn ten laste van een normale taak:

• In plaats van met het woord jobte beginnen, wordt een implementatietaak gedefinieerd als deployment.
• Het environment trefwoord geeft de naam op van de omgeving die moet worden gericht. In het voorgaande voorbeeld wordt de implementatie bijgehouden op basis van een omgeving met de naam MyAzureEnvironment.
• Het strategy trefwoord geeft aan hoe Azure Pipelines de implementatiestappen uitvoert. Implementatiestrategieën ondersteunen complexe implementatieprocessen, met name waar u meerdere productieomgevingen hebt. In deze module gebruiken we de runOnce implementatiestrategie. Deze strategie gedraagt zich op dezelfde manier als de andere taken die u al gewend bent.

Fasecontroles en goedkeuringen

Nadat u een omgeving hebt gemaakt, kunt u controles definiëren. Controles worden gebruikt om te controleren of aan voorwaarden moet worden voldaan voordat een pijplijn de omgeving kan gebruiken. Een goedkeuring is een type controle waarvoor een mens een handmatige goedkeuring moet verstrekken.

Controles worden gedefinieerd in de omgeving, niet de pijplijn. Auteurs van het YAML-pijplijnbestand kunnen deze controles en goedkeuringen niet verwijderen of toevoegen. Alleen de beheerders van een omgeving kunnen de controles en goedkeuringen beheren.

In veel organisaties is de eigenaar van een omgeving in Azure Pipelines de persoon die verantwoordelijk is voor de omgeving waarin deze wordt geïmplementeerd. Controles en goedkeuringen helpen ervoor te zorgen dat de juiste personen betrokken zijn bij het implementatieproces.

Hoe werken controles en goedkeuringen?

Controles en goedkeuringen worden vlak voordat een pijplijnfase begint geëvalueerd. Wanneer Azure Pipelines op het punt staat om een pijplijnfase uit te voeren, wordt gekeken naar alle pijplijnbronnen die in de fase worden gebruikt, inclusief omgevingen. Omgevingen kunnen controles hebben waaraan moet worden voldaan.

Een goedkeuring is één type controle. Wanneer u een goedkeuringscontrole configureert, wijst u een of meer gebruikers toe die de voortzetting van uw pijplijn moeten goedkeuren.

Azure Pipelines biedt ook andere typen controles. U kunt bijvoorbeeld een API aanroepen om aangepaste logica uit te voeren, de kantooruren te beheren waarop een fase kan worden uitgevoerd en zelfs query's uitvoeren op Azure Monitor om ervoor te zorgen dat een implementatie is geslaagd. We bespreken alleen goedkeuringscontroles in deze module, maar we bieden koppelingen naar meer informatie over controles in de samenvatting.

Notitie

Agentpools en serviceverbindingen kunnen ook controles hebben geconfigureerd. U kunt ook een speciale stap, een handmatige goedkeuringstaak genoemd, gebruiken. In deze module richten we ons echter op omgevingen en de controles die eraan zijn gekoppeld.

Nadat de pijplijn is gestart en een fase bereikt waarvoor een goedkeuringscontrole is vereist, wordt de pijplijnuitvoering onderbroken. Alle gebruikers die zijn aangewezen als goedkeurders, worden per e-mail een bericht verzonden in Azure DevOps.

Goedkeurders kunnen de pijplijnlogboeken inspecteren, zoals de wijzigingen die door de wat-als-bewerking worden gedetecteerd. Op basis van deze informatie worden de wijzigingen vervolgens goedgekeurd of geweigerd. Als ze de wijziging goedkeuren, wordt de pijplijn hervat. Als ze weigeren of als ze niet reageren binnen een configureerbare time-outperiode, mislukt de fase.

Het belang van goede praktijken

De omgevingsfunctie in Azure Pipelines biedt u de mogelijkheid om uw implementaties te koppelen aan een omgeving. Vervolgens neemt de implementatie de controles en goedkeuringen over die zijn gedefinieerd door de eigenaar van de omgeving. Er is echter niets om te vereisen dat nieuwe pijplijnen omgevingen gebruiken.

Het is belangrijk dat u en uw organisatie goede procedures vaststellen om uw pijplijndefinities te controleren. Een voorbeeld is het configureren van uw opslagplaats om pull-aanvraagbeoordelingen te vereisen voor wijzigingen in uw hoofdvertakking met behulp van beleidsregels voor vertakkingsbeveiliging. In een toekomstige module leert u meer over dit concept.

U kunt ook controles en goedkeuringen toevoegen aan serviceverbindingen die ervoor zorgen dat goedkeuring wordt verkregen voordat een implementatie de referenties van een service-principal kan gebruiken. De goedkeuringen zijn echter ook van invloed op de mogelijkheid van uw pijplijn om preflight-validatie en de wat-als-bewerking uit te voeren, omdat ze ook een serviceverbinding nodig hebben.

U kunt een andere, afzonderlijke serviceverbinding gebruiken voor de wat-als-fase met een eigen service-principal. De service-principal die wordt gebruikt voor de voorbereidende en validatiefasen moet een aangepaste Azure-rol hebben gedefinieerd om ervoor te zorgen dat deze over de minimale machtigingen beschikt die nodig zijn om het werk uit te voeren.