Esercizio - Aggiungere più ambienti al flusso di lavoro

7 minuti

In questo momento è possibile aggiornare il flusso di lavoro per eseguire la distribuzione in ambienti di test e di produzione. In questa unità si aggiornerà il flusso di lavoro per usare i flussi di lavoro chiamati in modo da poter riutilizzare i processi negli ambienti.

Durante il processo, si eseguiranno queste operazioni:

Aggiungere un flusso di lavoro riutilizzabile per il processo di linting.
Aggiungere un flusso di lavoro riutilizzabile che definisce i processi necessari per la distribuzione in un qualsiasi ambiente.
Aggiornare il flusso di lavoro per usare i flussi di lavoro chiamati.
Eseguire il flusso di lavoro e visualizzare i risultati.

Aggiungere un flusso di lavoro riutilizzabile per il processo di linting

Il processo di linting viene eseguito una sola volta durante l'esecuzione del flusso di lavoro, indipendentemente dal numero di ambienti in cui il flusso di lavoro esegue la distribuzione. Non è quindi necessario usare un flusso di lavoro chiamato per il processo di linting. Tuttavia, per fare in modo che il file principale di definizione del flusso di lavoro sia semplice e facile da leggere, si decide di definire il processo di linting in un file del flusso di lavoro separato.

In Visual Studio Code creare un nuovo file nella cartella .github/workflows denominata lint.yml.

Incollare la definizione di flusso di lavoro seguente nel file:

name: lint

on:
  workflow_call:

jobs:
  lint:
    name: Lint code
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Lint code
      run: |
        az bicep build --file deploy/main.bicep

Il processo di linting è lo stesso processo di linting già presente nel flusso di lavoro, ma ora si trova in un file del flusso di lavoro separato.

Salvare le modifiche e chiudere il file.

Aggiungere un flusso di lavoro riutilizzabile per la distribuzione

Creare un flusso di lavoro riutilizzabile che definisce tutti i processi necessari per distribuire ciascun ambiente. Gli input e i segreti risulteranno utili per specificare le impostazioni che potrebbero cambiare tra i diversi ambienti.

Creare un nuovo file nella cartella .github/workflows denominato deploy.yml.

Questo file rappresenta tutte le attività di distribuzione eseguite per ogni ambiente.
Incollare il nome del flusso di lavoro, il trigger, gli input e i segreti seguenti nel file:
```
name: deploy

on:
  workflow_call:
    inputs:
      environmentType:
        required: true
        type: string
      resourceGroupName:
        required: true
        type: string
    secrets:
      AZURE_CLIENT_ID:
        required: true
      AZURE_TENANT_ID:
        required: true
      AZURE_SUBSCRIPTION_ID:
        required: true
```
Nota

Quando si inizia a usare il file YAML in Visual Studio Code, è possibile che vengano visualizzate alcune righe ondulate rosse che segnalano un problema. Ciò è dovuto al fatto che l'estensione Visual Studio Code per i file YAML talvolta ipotizza in modo errato lo schema del file.

È possibile ignorare i problemi segnalati dall'estensione. In alternativa, se lo si desidera è possibile aggiungere il codice seguente all'inizio del file per evitare che l'estensione venga ipotizzata:
```
# yaml-language-server: $schema=./deploy.yml
```

Sotto i segreti incollare la definizione del processo di convalida:

jobs:
  validate:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v3
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - if: inputs.environmentType != 'Production'
       uses: azure/arm-deploy@v1
       name: Run preflight validation
       with:
         deploymentName: ${{ github.run_number }}
         resourceGroupName: ${{ inputs.resourceGroupName }}
         template: ./deploy/main.bicep
         parameters: >
           environmentType=${{ inputs.environmentType }}
         deploymentMode: Validate
     - if: inputs.environmentType == 'Production'
       uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ inputs.resourceGroupName }}
         template: ./deploy/main.bicep
         parameters: >
           environmentType=${{ inputs.environmentType }}
         additionalArguments: --what-if

Si noti che ai processi viene applicata una condizione. La convalida preliminare viene eseguita solo per ambienti che non sono di produzione. L'operazione di simulazione viene eseguita solo per ambienti che non sono di produzione. Nel modulo precedente del percorso di apprendimento sono stati usati processi separati per queste operazioni, ma in questo caso vengono combinati per semplificare il flusso di lavoro.

Suggerimento

I file YAML sono sensibili al rientro. Se si digita o si incolla questo codice, assicurarsi che il rientro sia corretto. Più avanti in questo esercizio verrà visualizzata la definizione completa del flusso di lavoro YAML in modo da verificare la corrispondenza del file.

Sotto il processo di convalida incollare la definizione del processo di distribuzione:

deploy:
  needs: validate
  environment: ${{ inputs.environmentType }}
  runs-on: ubuntu-latest
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy Bicep file
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ inputs.resourceGroupName }}
      template: ./deploy/main.bicep
      parameters: >
        environmentType=${{ inputs.environmentType }}

Sotto il processo di distribuzione incollare la definizione del processo di smoke test:

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

Verificare che il file deploy.yml ora sia simile all'esempio seguente:

name: deploy

on:
  workflow_call:
    inputs:
      environmentType:
        required: true
        type: string
      resourceGroupName:
        required: true
        type: string
    secrets:
      AZURE_CLIENT_ID:
        required: true
      AZURE_TENANT_ID:
        required: true
      AZURE_SUBSCRIPTION_ID:
        required: true

jobs:
  validate:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v3
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - if: inputs.environmentType != 'Production'
       uses: azure/arm-deploy@v1
       name: Run preflight validation
       with:
         deploymentName: ${{ github.run_number }}
         resourceGroupName: ${{ inputs.resourceGroupName }}
         template: ./deploy/main.bicep
         parameters: >
           environmentType=${{ inputs.environmentType }}
         deploymentMode: Validate
     - if: inputs.environmentType == 'Production'
       uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ inputs.resourceGroupName }}
         template: ./deploy/main.bicep
         parameters: >
           environmentType=${{ inputs.environmentType }}
         additionalArguments: --what-if

  deploy:
    needs: validate
    environment: ${{ inputs.environmentType }}
    runs-on: ubuntu-latest
    outputs:
      appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      name: Sign in to Azure
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      id: deploy
      name: Deploy Bicep file
      with:
        failOnStdErr: false
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ inputs.resourceGroupName }}
        template: ./deploy/main.bicep
        parameters: >
          environmentType=${{ inputs.environmentType }}

  smoke-test:
    runs-on: ubuntu-latest
    needs: deploy
    steps:
    - uses: actions/checkout@v3
    - run: |
        $container = New-PesterContainer `
          -Path 'deploy/Website.Tests.ps1' `
          -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
        Invoke-Pester `
          -Container $container `
          -CI
      name: Run smoke tests
      shell: pwsh

Salvare le modifiche apportate al file .

Aggiornare la definizione del flusso di lavoro per usare i modelli

Aprire il file workflow.yml nella cartella .github/workflows.
Rimuovere il contenuto della sezione env:, incluse le due variabili di ambiente. Queste variabili verranno sostituite a breve con variabili specifiche dell'ambiente.
Rimuovere il contenuto della definizione del processo lint: e sostituirlo con il codice seguente per usare il file lint.yml creato in precedenza:
```
# Lint the Bicep file.
lint:
  uses: ./.github/workflows/lint.yml
```
Eliminare tutto il contenuto del file sotto il processo di linting aggiornato.

Nella parte inferiore del file aggiungere il codice seguente per eseguire la distribuzione nell'ambiente di test:

# Deploy to the test environment.
deploy-test:
  uses: ./.github/workflows/deploy.yml
  needs: lint
  with:
    environmentType: Test
    resourceGroupName: ToyWebsiteTest
  secrets:
    AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Sotto il codice appena aggiunto, aggiungere il codice seguente per eseguire la distribuzione nell'ambiente di produzione:
```
# Deploy to the production environment.
deploy-production:
  uses: ./.github/workflows/deploy.yml
  needs: deploy-test
  with:
    environmentType: Production
    resourceGroupName: ToyWebsiteProduction
  secrets:
    AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
```
Il flusso di lavoro aggiornato esegue il processo lint una sola volta. Quindi usa il flusso di lavoro chiamato deploy.yml due volte: una volta per ogni ambiente. In questo modo la definizione del flusso di lavoro è chiara e facile da comprendere. I commenti nel file YAML identificano l'ambiente di destinazione di ogni processo.

Verificare che il file workflow.yml sia simile all'esempio seguente:

name: deploy-toy-website-environments
concurrency: toy-company

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:

  # Lint the Bicep file.
  lint:
    uses: ./.github/workflows/lint.yml

  # Deploy to the test environment.
  deploy-test:
    uses: ./.github/workflows/deploy.yml
    needs: lint
    with:
      environmentType: Test
      resourceGroupName: ToyWebsiteTest
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  # Deploy to the production environment.
  deploy-production:
    uses: ./.github/workflows/deploy.yml
    needs: deploy-test
    with:
      environmentType: Production
      resourceGroupName: ToyWebsiteProduction
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Salva le modifiche.
Eseguire il commit e il push delle modifiche nel repository Git eseguendo i comandi seguenti nel terminale di Visual Studio Code:
```
git add .
git commit -m "Add reusable workflows"
git push
```
Poiché è la prima volta che si esegue il push nel repository, potrebbe essere richiesto di eseguire l'accesso.

In Windows digitare 1 per eseguire l'autenticazione usando un Web browser e premere INVIO.

In macOS selezionare Autorizza.
Verrà visualizzata una finestra del browser. Potrebbe essere necessario accedere di nuovo a GitHub. Seleziona Autorizza.

Visualizzare l'esecuzione del flusso di lavoro

Nel browser passare ad Azioni.

La prima esecuzione del flusso di lavoro, denominata Initial commit, viene visualizzata come errore. GitHub ha eseguito automaticamente il flusso di lavoro al momento della creazione del repository. L'operazione non è riuscita perché i segreti non erano pronti in quel momento. È possibile ignorare questo errore.
Selezionare il flusso di lavoro deploy-toy-website-environments.
Selezionare l'esecuzione più recente del flusso di lavoro.

Si noti che l'esecuzione del flusso di lavoro mostra ora tutti i processi definiti nei file YAML.

Alcuni avvisi sono elencati nel pannello Annotazioni. Tutti questi avvisi sono dovuti al modo in cui Bicep scrive i messaggi informativi nel log del flusso di lavoro. È possibile ignorare questi avvisi.
Attendere che il flusso di lavoro venga sospeso prima del processo deploy-production / deploy. Potrebbero essere necessari alcuni minuti prima che il flusso di lavoro raggiunga questo punto.
Approvare la distribuzione nell'ambiente di produzione selezionando il pulsante Review deployments (Esamina le distribuzioni).
Selezionare l'ambiente Produzione, quindi selezionare il pulsante Approve and deploy (Approva e distribuisci).

Attendere il completamento dell'esecuzione del flusso di lavoro. Il flusso di lavoro viene completato correttamente.
Selezionare Codice.
Selezionare la distribuzione Produzione.
Si noti che nella schermata di distribuzione viene visualizzata una panoramica della cronologia di distribuzione dell'ambiente di produzione.
Selezionare l'identificatore del commit.

Si noti che GitHub mostra l'elenco dei commit inclusi nella distribuzione. Ciò consente di visualizzare le modifiche nell'ambiente nel tempo.
Nel browser passare al portale di Azure.
Passare al gruppo di risorse ToyWebsiteProduction.
Nell'elenco delle risorse aprire l'app Servizio app di Azure.

Si noti che il tipo di piano di servizio app è S1.
Passare all'app del servizio app nel gruppo di risorse ToyWebsiteTest.

Si noti che il tipo di piano di servizio app è F1. I due ambienti usano impostazioni diverse, come definito dall'utente nel file Bicep.

Esercizio - Aggiungere più ambienti al flusso di lavoro

Aggiungere un flusso di lavoro riutilizzabile per il processo di linting

Aggiungere un flusso di lavoro riutilizzabile per la distribuzione

Aggiornare la definizione del flusso di lavoro per usare i modelli

Visualizzare l'esecuzione del flusso di lavoro

Commenti e suggerimenti