Exercício - Adicione fiapos e valide trabalhos ao seu fluxo de trabalho

  • 3 minutos

Você falou com sua equipe e decidiu automatizar ainda mais suas implantações usando um fluxo de trabalho. Você quer construir mais confiança no que implanta.

Neste exercício, você adicionará trabalhos de validação ao seu fluxo de trabalho. Em seguida, você executará a validação de linter e comprovação antes de cada implantação.

Durante o processo, você executa as seguintes tarefas:

  • Atualize seu fluxo de trabalho existente para adicionar dois novos trabalhos ao lint e validar seu código Bicep.
  • Execute seu fluxo de trabalho.
  • Corrija quaisquer problemas que o seu fluxo de trabalho detete.

Adicione fiapos e trabalhos de validação ao seu fluxo de trabalho

  1. No Visual Studio Code, abra o arquivo workflow.yml na pasta .github/workflows .

  2. env: Na seção , altere o AZURE_RESOURCEGROUP_NAME valor da variável para ToyWebsiteTest:

    env:
  AZURE_RESOURCEGROUP_NAME: ToyWebsiteTest
  ENVIRONMENT_TYPE: Test

  3. Abaixo da jobs: linha, acima do deploy trabalho, adicione um novo trabalho de fiapos:

    jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file deploy/main.bicep

    Este trabalho define uma etapa para verificar o código e uma etapa que executa o az bicep build comando para lint o arquivo Bicep.

    Gorjeta

    Os arquivos YAML são sensíveis ao recuo. Quer escreva ou cole este código, certifique-se de que o recuo está correto. Mais adiante neste exercício, você verá a definição completa do fluxo de trabalho do YAML para que possa verificar se o arquivo corresponde.

  4. Abaixo das linhas que você acabou de adicionar e acima do trabalho de implantação, adicione um trabalho de validação:

    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 }}
  - uses: azure/arm-deploy@v1
    name: Run preflight validation
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
      deploymentMode: Validate

    Este trabalho define etapas para fazer check-out do código, entrar em seu ambiente do Azure e usar a azure/arm-deploy ação com o Validate modo de implantação.

    Sua definição de fluxo de trabalho agora tem três trabalhos. O primeiro lints seu arquivo Bicep, o segundo executa uma validação de comprovação e o terceiro executa a implantação no Azure.

  5. Abaixo da runs-on linha no deploy trabalho, adicione uma needs instrução:

    deploy:
  runs-on: ubuntu-latest
  needs: [lint, validate]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure

    A needs instrução indica que o trabalho de implantação depende do lint e valida os trabalhos concluídos com êxito antes que ele possa ser executado.

    Observe também que os trabalhos de validação e implantação entram no Azure, e todos os trabalhos fazem check-out do código do repositório. Essas etapas são necessárias porque cada trabalho usa um novo corredor do GitHub.

  6. Guarde o ficheiro.

Configurar o linter

Por padrão, o linter do Bíceps fornece um aviso quando deteta um problema com seu arquivo. O GitHub Actions não trata os avisos linter como problemas que devem parar seu fluxo de trabalho. Para personalizar esse comportamento, crie um arquivo de bicepconfig.json que reconfigura o linter.

  1. Adicione um novo arquivo na pasta deploy e nomeie-o bicepconfig.json.

    Captura de tela do Visual Studio Code Explorer, com o novo arquivo mostrado na pasta de implantação.

  2. Copie e cole o seguinte código no arquivo:

    {
  "analyzers": {
    "core": {
      "enabled": true,
      "verbose": true,
      "rules": {
        "adminusername-should-not-be-literal": {
          "level": "error"
        },
        "max-outputs": {
          "level": "error"
        },
        "max-params": {
          "level": "error"
        },
        "max-resources": {
          "level": "error"
        },
        "max-variables": {
          "level": "error"
        },
        "no-hardcoded-env-urls": {
          "level": "error"
        },
        "no-unnecessary-dependson": {
          "level": "error"
        },
        "no-unused-params": {
          "level": "error"
        },
        "no-unused-vars": {
          "level": "error"
        },
        "outputs-should-not-contain-secrets": {
          "level": "error"
        },
        "prefer-interpolation": {
          "level": "error"
        },
        "secure-parameter-default": {
          "level": "error"
        },
        "simplify-interpolation": {
          "level": "error"
        },
        "protect-commandtoexecute-secrets": {
          "level": "error"
        },
        "use-stable-vm-image": {
          "level": "error"
        }
      }
    }
  }
}

  3. Guarde o ficheiro.

Configurar o trabalho de implantação para trabalhar com o linter

Quando você usa uma configuração linter personalizada, o Bicep grava dados de log que o GitHub Actions interpreta como um erro. Para desativar esse comportamento, configure a arm-deploy tarefa para ignorar o fluxo de log de erro padrão (stderr).

  1. Abra o arquivo workflow.yml .

  2. deploy Na etapa de teste Implantar site do trabalho, defina a failOnStdErr propriedade comofalse:

    deploy:
  runs-on: ubuntu-latest
  needs: [lint, validate]
  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
    name: Deploy website
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

  3. Guarde o ficheiro.

Verificar e confirmar sua definição de fluxo de trabalho

  1. Verifique se o arquivo workflow.yml se parece com o seguinte código:

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

on:
  push:
    branches:
      - main

permissions:
  id-token: write
  contents: read

env:
  AZURE_RESOURCEGROUP_NAME: ToyWebsiteTest
  ENVIRONMENT_TYPE: Test

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file deploy/main.bicep

  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 }}
    - uses: azure/arm-deploy@v1
      name: Run preflight validation
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    needs: [lint, validate]
    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
      name: Deploy website
      with:
        failOnStdErr: false
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

    Se o ficheiro tiver um aspeto diferente, atualize-o para corresponder a este exemplo e, em seguida, guarde-o.

  2. Confirme e envie suas alterações para o repositório Git executando os seguintes comandos no terminal do Visual Studio Code:

    git add .
git commit -m "Add lint and validation jobs"
git push

  3. Essa confirmação é a primeira vez que você envia por push para esse repositório, portanto, você pode ser solicitado a entrar.

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

    No macOS, selecione Autorizar.

  4. É apresentada uma janela do browser. Talvez seja necessário fazer login no GitHub novamente. Selecionar Autorizar.

    Imediatamente após o envio, o GitHub Actions inicia uma nova execução de fluxo de trabalho.

Exibir a execução do fluxo de trabalho

  1. No navegador, vá para Ações.

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

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

    Captura de tela das Ações do GitHub com o link para a execução mais recente do fluxo de trabalho realçado.

    Observe que a execução do fluxo de trabalho agora mostra os três trabalhos que você definiu no arquivo YAML. Os trabalhos lint e validate são executados em paralelo antes do início do trabalho de implantação .

  3. Se o fluxo de trabalho ainda estiver em execução, aguarde até que seja concluído. Embora os fluxos de trabalho atualizem automaticamente a página com o status mais recente, é uma boa ideia atualizá-la ocasionalmente.

    Observe que os trabalhos de fiapos e validação falharam.

    Captura de tela de um fluxo de trabalho executado no GitHub Actions, com os trabalhos Lint e Validate relatando falha.

  4. Selecione o trabalho de fiapos para ver seus detalhes.

  5. Selecione a etapa Executar linter do Bicep para exibir o log do fluxo de trabalho.

    Captura de tela do log de fluxo de trabalho para o trabalho Lint, com a etapa para executar um linter Bicep realçada.

    O erro no log do fluxo de trabalho inclui uma mensagem de erro linter:

    Error no-unused-params: Parameter "storageAccountNameParam" is declared but never used.

    Essa mensagem de erro indica que o linter encontrou uma violação de regra em seu arquivo Bicep.

Corrigir o erro linter

Agora que você identificou o problema, você pode corrigi-lo em seu arquivo Bicep.

  1. No Visual Studio Code, abra o arquivo main.bicep na pasta deploy .

  2. Observe que o linter do Bíceps também detetou que o storageAccountNameParam parâmetro não é usado. No Visual Studio Code, uma linha ondulada é exibida sob o parâmetro. Normalmente, a linha seria amarela para indicar um aviso. Mas como você personalizou o arquivo bicepconfig.json , o linter trata o código como um erro e exibe a linha em vermelho.

    param storageAccountNameParam string = uniqueString(resourceGroup().id)

  3. Exclua o storageAccountNameParam parâmetro.

  4. Guarde o ficheiro.

  5. Confirme e envie suas alterações para o repositório Git executando os seguintes comandos no terminal do Visual Studio Code:

    git add .
git commit -m "Remove unused parameter"
git push

    Mais uma vez, o GitHub Actions aciona automaticamente uma nova execução do seu fluxo de trabalho.

Exibir o fluxo de trabalho executado novamente

  1. No navegador, acesse o fluxo de trabalho.

  2. Selecione a execução mais recente.

    Aguarde até que a execução do fluxo de trabalho seja concluída. Embora o GitHub Actions atualize automaticamente a página com o status mais recente, é uma boa ideia atualizá-la ocasionalmente.

  3. Observe que o trabalho lint foi concluído com êxito, mas o trabalho de validação ainda está falhando.

    Captura de tela da execução do fluxo de trabalho, com o sucesso do relatório de trabalho do Lint e a falha do relatório de trabalho Validar.

  4. Selecione o trabalho de validação para ver seus detalhes.

  5. Selecione a etapa Executar validação de comprovação para exibir o log do fluxo de trabalho.

    Captura de tela do log de fluxo de trabalho para o trabalho Validar, com a etapa para executar a validação de comprovação realçada.

    O erro exibido no log do fluxo de trabalho inclui a seguinte mensagem:

    mystorageresourceNameSuffix is not a valid storage account name. Storage account name must be between 3 and 24 characters in length and use numbers and lower-case letters only.

    Este erro indica que o nome da conta de armazenamento não é válido.

Corrigir o erro de validação

Você encontrou outro problema no arquivo Bicep. Aqui, você corrige o problema.

  1. No Visual Studio Code, abra o arquivo main.bicep na pasta deploy .

  2. Veja a definição da storageAccountName variável:

    var appServiceAppName = 'toy-website-${resourceNameSuffix}'
var appServicePlanName = 'toy-website'
var logAnalyticsWorkspaceName = 'workspace-${resourceNameSuffix}'
var applicationInsightsName = 'toywebsite'
var storageAccountName = 'mystorageresourceNameSuffix'

    Parece haver um erro de digitação e a interpolação de cadeia de caracteres não está configurada corretamente.

  3. Atualize a variável para usar a storageAccountName interpolação de cadeia de caracteres corretamente:

    var storageAccountName = 'mystorage${resourceNameSuffix}'

  4. Guarde o ficheiro.

  5. Confirme e envie suas alterações para o repositório Git executando os seguintes comandos no terminal do Visual Studio Code:

    git add .
git commit -m "Fix string interpolation"
git push

Exibir a execução bem-sucedida do fluxo de trabalho

  1. No navegador, acesse o fluxo de trabalho.

  2. Selecione a execução mais recente.

    Aguarde até que a execução do fluxo de trabalho seja concluída. Embora o GitHub Actions atualize automaticamente a página com o status mais recente, é uma boa ideia atualizá-la ocasionalmente.

  3. Observe que todos os três trabalhos no fluxo de trabalho foram concluídos com êxito:

    Captura de tela do fluxo de trabalho executado nas Ações do GitHub, com todos os três trabalhos relatando o sucesso.

    Alguns avisos estão listados no painel Anotações . Esses avisos aparecem devido à maneira como o Bicep grava mensagens informativas no log do fluxo de trabalho. Você pode ignorar esses avisos.

Agora você tem um fluxo de trabalho que deteta erros com êxito no código do Bicep no início do processo de implantação e, em seguida, implanta no Azure se não houver erros.