Exercício – adicionar vários ambientes ao seu pipeline

  • 7 minutos

Agora você está pronto para atualizar seu fluxo de trabalho para fazer a implantação em seus ambientes de teste e produção. Nesta unidade, você atualizará seu fluxo de trabalho para usar fluxos de trabalho chamados para que você possa reutilizar os trabalhos em todos os ambientes.

Durante o processo, você vai:

  • Adicionar um fluxo de trabalho reutilizável para o trabalho de lint.
  • Adicionar um fluxo de trabalho reutilizável que defina os trabalhos necessários para fazer a implantação em qualquer ambiente.
  • Atualizar seu fluxo de trabalho para usar os fluxos de trabalho chamados.
  • Executar seu fluxo de trabalho e exibir os resultados.

Adicionar um fluxo de trabalho reutilizável para o trabalho de lint

O trabalho de lint ocorre apenas uma vez durante a execução do fluxo de trabalho, independentemente de em quantos ambientes o fluxo de trabalho faz a implantação. Portanto, você não precisa usar um fluxo de trabalho chamado para o trabalho de lint. Mas, para manter o arquivo de definição de fluxo de trabalho principal simples e fácil de ler, você decide definir o trabalho de lint em um arquivo de fluxo de trabalho separado.

  1. No Visual Studio Code, crie um arquivo na pasta .github/workflows chamada lint.yml.

    Captura de tela do Explorador do Visual Studio Code, com as pastas .github e workflows e o arquivo lint .YML.

  2. Cole a seguinte definição de fluxo de trabalho no arquivo:

    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

    O trabalho de lint é o mesmo que o trabalho de lint já no fluxo de trabalho, mas agora ele está em um arquivo de fluxo de trabalho separado.

  3. Salve suas alterações e feche o arquivo.

Adicionar um fluxo de trabalho reutilizável para implantação

Crie um fluxo de trabalho reutilizável que define todos os trabalhos necessários para fazer a implantação em cada um dos seus ambientes. Você usará entradas e segredos para especificar as configurações que podem ser diferentes entre ambientes.

  1. Crie um arquivo na pasta .github/workflows, chamada deploy.yml.

    Captura de tela do Explorador do Visual Studio Code, com as pastas .github e workflows e o arquivo de implantação .YML.

    Esse arquivo representa todas as atividades de implantação executadas para cada um dos ambientes.

  2. Cole o seguinte nome de fluxo de trabalho, gatilho, entradas e segredos no arquivo:

    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

    Observação

    Quando você começar a trabalhar com o arquivo YAML no Visual Studio Code, poderá ver algumas linhas onduladas vermelhas informando que há um problema. Isso ocorre porque a extensão do Visual Studio Code para arquivos YAML às vezes supõe incorretamente o esquema do arquivo.

    Você pode ignorar os problemas que a extensão relata. Ou, se preferir, você pode adicionar o seguinte código à parte superior do arquivo para suprimir a suposição da extensão:

    # yaml-language-server: $schema=./deploy.yml

  3. Embaixo dos segredos, cole a definição do trabalho de validação:

    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

    Observe que uma condição é aplicada aos trabalhos. A validação de simulação é executada somente para ambientes que não são de produção. A operação what-if é executada somente para o ambiente de produção. No módulo anterior no roteiro de aprendizagem, você usou trabalhos separados para essas operações, mas aqui você os combinará para simplificar o fluxo de trabalho.

    Dica

    Os arquivos YAML são sensíveis ao recuo. Independentemente de você digitar ou colar esse código, verifique se o recuo está correto. Posteriormente neste exercício, você verá a definição completa do fluxo de trabalho YAML para verificar se o arquivo é correspondente.

  4. Embaixo do trabalho de validação, cole a definição do trabalho de implantação:

    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 }}

  5. Embaixo do trabalho de implantação, cole a definição do trabalho de 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

  6. Verifique se o arquivo deploy.yml agora se parece com o seguinte exemplo:

    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

  7. Salve as alterações no arquivo.

Atualizar a definição de fluxo de trabalho para usar os modelos

  1. Abra o arquivo workflow.yml na pasta .github/workflows.

  2. Remova o conteúdo da seção env:, incluindo as duas variáveis de ambiente. Você as substituirá em breve por conjuntos de variáveis específicas do ambiente.

  3. Remova o conteúdo da definição de trabalho lint: e substitua-o pelo seguinte código para usar o arquivo lint.yml criado anteriormente:

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

  4. Exclua tudo no arquivo embaixo do trabalho lint que você acabou de atualizar.

  5. Na parte inferior do arquivo, adicione o seguinte código para fazer a implantação no ambiente de teste:

    # 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 }}

  6. Embaixo do código que você acabou de adicionar, adicione o seguinte código para fazer a implantação no ambiente de produção:

    # 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 }}

    Seu fluxo de trabalho atualizado executa o trabalho lint uma vez. Em seguida, ele usa o fluxo de trabalho chamado deploy.yml duas vezes: uma vez por ambiente. Isso mantém a definição de fluxo de trabalho clara e fácil de entender. Os comentários no arquivo YAML identificam o ambiente de destino de cada trabalho.

  7. Verifique se o arquivo workflow.yml é semelhante ao seguinte exemplo:

    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 }}

  8. Salve suas alterações.

  9. Faça commit e efetue push das alterações no repositório Git executando os seguintes comandos no terminal do Visual Studio Code:

    git add .
git commit -m "Add reusable workflows"
git push

  10. Como essa é a primeira vez que você faz push para o repositório, talvez seja solicitado que você faça login.

    No Windows, digite 1 para autenticar usando um navegador da Web e selecione Enter.

    No macOS, selecione Autorizar.

  11. Uma janela do navegador é exibida. Talvez seja necessário entrar no GitHub novamente. Selecione Autorizar.

Ver a execução do fluxo de trabalho

  1. No navegador, acesse Ações.

    A primeira execução do fluxo de trabalho, Commit Inicial, é mostrada como uma falha. O GitHub executou automaticamente o fluxo de trabalho quando você criou o repositório. Ele falhou porque os segredos não estavam prontos naquele momento. Você pode ignorar essa falha.

  2. Selecione o fluxo de trabalho deploy-toy-website-environments.

  3. Selecione a execução mais recente do fluxo de trabalho.

    Observe que a execução do fluxo de trabalho agora mostra todos os trabalhos que você definiu nos arquivos YAML.

    Alguns avisos são listados no painel Anotações. Todos esses avisos são causados pela maneira como o Bicep grava mensagens informativas no log do fluxo de trabalho. Você pode ignorar esses avisos.

  4. Aguarde até que o fluxo de trabalho seja pausado antes do trabalho deploy-production / deploy. Pode levar alguns minutos para o pipeline chegar a esse ponto.

    Captura de tela do GitHub que mostra a execução do fluxo de trabalho em pausa para aprovação.

  5. Aprove a implantação no ambiente de produção selecionando o botão Examinar implantações.

  6. Selecione o ambiente de produção e, em seguida, selecione o botão Aprovar e implantar.

    Captura de tela da interface do GitHub que mostra a página de aprovação do fluxo de trabalho e o botão Aprovar e implantar.

    Aguarde até que a execução do fluxo de trabalho seja concluída. O fluxo de trabalho é concluído com êxito.

  7. Selecione Código.

  8. Selecione a implantação Produção.

    Captura de tela do GitHub que mostra o ambiente de página de código, com o ambiente de produção realçado.

  9. Observe que, na tela de implantação, há uma visão geral do histórico de implantação do ambiente de produção.

    Captura de tela do GitHub que apresenta o ambiente de produção, com o histórico de implantação mostrando uma única implantação.

  10. Selecione o identificador de confirmação.

    Observe que o GitHub mostra a lista de commits incluídos na implantação. Isso ajuda você a ver as alterações em seu ambiente ao longo do tempo.

    Captura de tela do GitHub que mostra os detalhes de implantação do ambiente de produção, com uma lista de commits.

  11. No navegador, acesse o portal do Azure.

  12. Vá para o grupo de recursos ToyWebsiteProduction.

  13. Na lista de recursos, abra o aplicativo Serviço de Aplicativo do Azure.

    Captura de tela do portal do Azure que mostra o aplicativo de produção do site de brinquedos dos Serviços de Aplicativo e os detalhes do SKU do plano do Serviço de Aplicativo.

    Observe que o tipo de plano do serviço de aplicativo é S1.

  14. Vá para o aplicativo Serviço de Aplicativo no grupo de recursos ToyWebsiteTest.

    Observe que o tipo de plano do serviço de aplicativo é F1. Os dois ambientes usam configurações diferentes, como você definiu em seu arquivo Bicep.