Gerenciar regras de qualidade de dados como código com o Terraform, o Cloud Build e o GitHub

Definir regras de qualidade de dados automática como código no Knowledge Catalog (antigo Dataplex Universal Catalog) permite controlar as versões das regras de validação e aplicar verificações de forma consistente em conjuntos de dados específicos do ambiente. Neste tutorial, você vai conectar o GitHub e o Cloud Build para visualizar as mudanças do Terraform em solicitações de pull e promover verificações de qualidade do desenvolvimento para as tabelas do BigQuery de produção. Para mais informações, consulte Visão geral da qualidade de dados automática, Visão geral do Terraform no Google Cloud e Visão geral do Cloud Build.

Arquitetura

Ao manter versões separadas de um conjunto de dados em ambientes como dev e prod, o Terraform oferece uma maneira confiável de atribuir regras de qualidade de dados a cada conjunto de dados. O diagrama a seguir mostra como este tutorial usa o Cloud Build para gerenciar execuções do Terraform em ramificações do GitHub:

Observação :para simplificar, este tutorial implementa apenas ambientes dev e prod. É possível ampliar esse comportamento para fazer implantações em mais ambientes e criar projetos na hierarquia organizacional, se necessário.

O processo começa quando você envia o código do Terraform para a ramificação dev ou prod. Nesse cenário, o Cloud Build aciona gatilhos de build e aplica manifestos do Terraform para atingir o estado desejado no respectivo ambiente. Por outro lado, quando você aplica o código do Terraform a qualquer outra ramificação, como uma ramificação de recurso, o Cloud Build é iniciado para executar terraform plan, mas nada é aplicado a ambiente algum.

O ideal é que desenvolvedores ou operadores façam propostas de infraestrutura para ramificações não protegidas e as enviem usando solicitações de pull. O app GitHub do Cloud Build, discutido posteriormente neste tutorial, aciona automaticamente os jobs de build e vincula os relatórios terraform plan a essas solicitações de pull. Dessa forma, é possível discutir e analisar as possíveis alterações com os colaboradores e adicionar confirmações de acompanhamento antes que as alterações sejam mescladas no branch básico.

Se não houver preocupações, mescle as alterações no branch dev. Essa mescla aciona uma implantação de infraestrutura para o ambiente dev, o que permite testá-lo. Depois de testar e ter certeza do que foi implantado, mescle o branch dev no branch prod para acionar a instalação da infraestrutura no ambiente de produção.

Objetivos

• Configurar seu repositório GitHub.
• Configurar o Terraform para armazenar o estado em um bucket do Cloud Storage.
• Conceder permissões à conta de serviço do Cloud Build.
• Conectar o Cloud Build ao seu repositório GitHub.
• Estabelecer regras de qualidade de dados do Knowledge Catalog.
• Alterar a configuração do ambiente em uma ramificação de recurso e testar.
• Promover mudanças no ambiente de desenvolvimento.
• Promover mudanças no ambiente de produção.

Custos

Neste documento, você vai usar os seguintes componentes faturáveis do Google Cloud:

• BigQuery
• Cloud Build
• Cloud Storage
• Compute Engine
• Knowledge Catalog

Para gerar uma estimativa de custo baseada na sua projeção de uso, use a calculadora de preços.

Novos usuários do Google Cloud podem estar qualificados para um teste sem custo financeiro.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Para mais informações, consulte Limpeza.

Antes de começar

Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho sem custos financeiros.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. No console do Google Cloud , ative o Cloud Shell.

   Ativar o Cloud Shell

   Na parte inferior do console do Google Cloud , uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

2. No Cloud Shell, consiga o código do projeto que você acabou de selecionar:

   gcloud config get-value project

   Se esse comando não retornar o ID, configure o Cloud Shell para usar seu projeto. Substitua PROJECT_ID pelo ID do projeto.

   gcloud config set project PROJECT_ID

3. Ative as APIs necessárias:

   gcloud services enable bigquery.googleapis.com cloudbuild.googleapis.com compute.googleapis.com dataplex.googleapis.com

   Essa etapa pode levar alguns minutos.
4. Se você nunca usou o Git no Cloud Shell, configure-o com seu nome e endereço de e-mail:

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

   O Git usa essas informações para identificar você como autor dos commits criados no Cloud Shell.

Configurar seu repositório GitHub

O controle de versões é uma prática recomendada importante de DevOps, e o gerenciamento das regras de qualidade de dados como código mantém as versões anteriores das regras disponíveis no histórico do GitHub. Neste tutorial, você usa um único repositório do Git para definir a infraestrutura em nuvem. Você orquestra essa infraestrutura ao ter branches diferentes que correspondem a ambientes diferentes:

• A ramificação dev contém as alterações mais recentes aplicadas ao ambiente de desenvolvimento.
• A ramificação prod contém as últimas alterações que são aplicadas ao ambiente de produção.

Com essa infraestrutura, sempre é possível fazer referência ao repositório para saber qual configuração é esperada em cada ambiente e propor novas alterações, primeiro fundindo-as ao ambiente dev. Em seguida, você promove as alterações mesclando a ramificação dev na ramificação prod.

Para começar, bifurque o repositório terraform-google-dataplex-auto-data-quality.

1. No GitHub, acesse https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git.

2. Clique em Bifurcar.

   Agora você tem uma cópia do repositório terraform-google-dataplex-auto-data-quality com arquivos de origem.

3. No Cloud Shell, clone o seguinte repositório bifurcado:

   cd ~
   git clone https://github.com/GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality.git
   cd ~/terraform-google-dataplex-auto-data-quality
   

   Substitua:

   • GITHUB_USERNAME: seu nome de usuário do GitHub

4. Crie as ramificações dev e prod:

   git checkout -b prod
   git checkout -b dev
   

O código nesse repositório está estruturado da seguinte maneira:

• A pasta environments/ contém subpastas que representam ambientes, como dev e prod, que fornecem separação lógica entre cargas de trabalho em diferentes estágios de maturidade, desenvolvimento e produção, respectivamente.

• A pasta modules/ contém módulos in-line do Terraform. Esses módulos representam agrupamentos lógicos de recursos relacionados e são usados para compartilhar código em diferentes ambientes. O módulo modules/deploy/ aqui representa um modelo para uma implantação e é reutilizado para diferentes ambientes de implantação.

• Em modules/deploy/:

  • A pasta rule/ contém arquivos yaml com regras de qualidade de dados. Um arquivo representa um conjunto de regras de qualidade de dados para uma tabela. Esse arquivo é usado nos ambientes dev e prod.

  • A pasta schemas/ contém o esquema da tabela do BigQuery implantada nessa infraestrutura.

  • O arquivo bigquery.tf contém a configuração das tabelas do BigQuery criadas nessa implantação.

  • O arquivo dataplex.tf contém uma verificação de dados do Knowledge Catalog para qualidade de dados. Esse arquivo é usado em conjunto com rules_file_parsing.tf para ler regras de qualidade de dados de um arquivo yaml no ambiente.

• O cloudbuild.yaml é um arquivo de configuração de build que contém instruções para o Cloud Build, por exemplo, como executar tarefas com base em um conjunto de etapas. Esse arquivo especifica uma execução condicional, dependendo do branch em que o Cloud Build está buscando o código. Por exemplo:

  • Para ramificações dev e prod, as seguintes etapas são executadas:

    1. terraform init
    2. terraform plan
    3. terraform apply

  • Para qualquer outra ramificação, as etapas a seguir são executadas:

    1. terraform init para todas as subpastas environments
    2. terraform plan para todas as subpastas environments

Para garantir que as alterações propostas sejam adequadas para todos os ambientes, terraform init e terraform plan são executados em todos os ambientes. Antes de mesclar a solicitação de envio, é possível analisar os planos para garantir que o acesso não seja concedido a uma entidade não autorizada, por exemplo.

Configurar o Terraform para armazenar o estado em buckets do Cloud Storage

O Terraform usa o estado para mapear recursos para sua configuração, acompanhar metadados e melhorar o desempenho de grandes infraestruturas. Por padrão, o Terraform armazena o estado localmente em um arquivo chamado terraform.tfstate. Essa configuração padrão pode dificultar o uso do Terraform para as equipes, especialmente quando muitos usuários o executam ao mesmo tempo e cada máquina tem o próprio entendimento da infraestrutura atual.

Para ajudar a evitar esses problemas, esta seção configura um estado remoto que aponta para um bucket do Cloud Storage, que também pode armazenar versões anteriores do arquivo de estado. O estado remoto é um recurso de back-ends e, neste tutorial, é configurado no arquivo backend.tf.

# Copyright 2024 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate-dev"
  }
}

Há um arquivo backend.tf separado em cada um dos ambientes dev e prod. Consideramos uma prática recomendada usar um bucket do Cloud Storage diferente para cada ambiente.

Nas etapas a seguir, você vai criar dois buckets do Cloud Storage para dev e prod e mudar alguns arquivos para apontar para os novos buckets e o projeto doGoogle Cloud .

1. No Cloud Shell, crie os dois buckets do Cloud Storage:

   DEV_BUCKET=gs://PROJECT_ID-tfstate-dev
   gcloud storage buckets create ${DEV_BUCKET}
   
   PROD_BUCKET=gs://PROJECT_ID-tfstate-prod
   gcloud storage buckets create ${PROD_BUCKET}
   

2. Para manter o histórico das implantações, ative o Controle de versões de objeto:

   gcloud storage buckets update ${DEV_BUCKET} --versioning
   gcloud storage buckets update ${PROD_BUCKET} --versioning
   

   Ativar o controle de versões de objetos aumenta os custos de armazenamento, que podem ser reduzidos com a configuração do Gerenciamento do ciclo de vida de objetos para excluir versões de estado mais antigas.

3. Em cada ambiente, nos arquivos main.tf e backend.tf , substitua PROJECT_ID pelo ID do projeto:

   cd ~/terraform-google-dataplex-auto-data-quality
   sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
   sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/backend.tf
   

   No SO X ou macOS, talvez seja necessário adicionar duas aspas ("") depois de sed -i, da seguinte maneira:

   cd ~/solutions-terraform-cloudbuild-gitops
   sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
   sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/backend.tf
   

4. Verifique se todos os arquivos foram atualizados:

   git status
   

   Veja um exemplo de saída:

   On branch dev
   Your branch is up-to-date with 'origin/dev'.
   Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
          modified:   environments/dev/backend.tf
          modified:   environments/dev/main.tf
          modified:   environments/prod/backend.tf
          modified:   environments/prod/main.tf
   no changes added to commit (use "git add" and/or "git commit -a")
   

5. Confirme e envie suas alterações por push:

   git add --all
   git commit -m "Update project IDs and buckets"
   git push origin dev
   

   Dependendo da sua configuração do GitHub, talvez seja necessário realizar a autenticação para enviar as alterações anteriores.

Conceder permissões à conta de serviço do Cloud Build

Para permitir que a conta de serviço do Cloud Build execute scripts do Terraform para gerenciar os recursos do Google Cloud , você precisa conceder acesso adequado ao projeto. Para simplificar, o acesso de editor do projeto é concedido neste tutorial. Porém, quando o papel de editor do projeto tem uma permissão ampla, em ambientes de produção, siga as práticas recomendadas de segurança de TI da sua empresa, geralmente fornecendo acesso com menos privilégios.

1. No Cloud Shell, recupere o e-mail da conta de serviço do Cloud Build no projeto:

   CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
       --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"
   

2. Conceda o acesso necessário à sua conta de serviço do Cloud Build:

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member serviceAccount:$CLOUDBUILD_SA --role roles/editor
   

Como conectar diretamente o Cloud Build ao seu repositório GitHub

Nesta seção, descrevemos como instalar o app GitHub do Cloud Build. Essa instalação permite que você conecte o repositório do GitHub ao projeto doGoogle Cloud para que o Cloud Build possa aplicar automaticamente seus manifestos do Terraform toda vez que você criar uma nova ramificação ou enviar um código ao GitHub.

As etapas a seguir só fornecem instruções para instalar o app para o repositório terraform-google-dataplex-auto-data-quality, mas você pode optar por instalar o app para mais repositórios ou todos eles.

1. No Marketplace do GitHub, acesse a página do app Cloud Build.

   • Se esta for a primeira vez que você configura um app no GitHub, clique em Configurar com o Google Cloud Build na parte inferior da página. Em seguida, clique em Conceder acesso à sua conta do GitHub para o app.
   • Se esta não for a primeira vez que você configura um app no GitHub, clique em Configurar acesso. A página Aplicativos da sua conta pessoal é aberta.

2. Clique em Configurar na linha do Cloud Build.

3. Selecione Somente repositórios selecionados e clique em terraform-google-dataplex-auto-data-quality para se conectar ao repositório.

4. Clique em Salvar ou em Instalar. O rótulo do botão muda dependendo do fluxo de trabalho. Você vai acessar o Google Cloud para continuar a instalação.

5. Faça login com sua conta do Google Cloud . Se solicitado, autorize a integração do Cloud Build com o GitHub.

6. Na página Cloud Build, selecione o projeto. Um assistente será exibido.

7. Na seção Selecionar repositório, escolha sua conta do GitHub e o repositório terraform-google-dataplex-auto-data-quality.

8. Se você concordar com os termos e condições, marque a caixa de seleção e clique em Conectar.

9. Na seção Criar gatilho, clique em Criar gatilho:

   1. Adicione um nome para o gatilho, como push-to-branch. Anote esse nome do gatilho porque você vai precisar dele mais tarde.
   2. Na seção Evento, selecione Enviar para uma ramificação.
   3. Na seção Origem, selecione .* no campo Ramificação.
   4. Clique em Criar.

O app GitHub do Cloud Build está configurado, e seu repositório do GitHub está vinculado ao projeto do Google Cloud . As alterações feitas no repositório do GitHub acionam execuções do Cloud Build, que informam os resultados ao GitHub usando as verificações do GitHub.

Alterar a configuração do ambiente em uma nova ramificação de recurso

A maior parte do seu ambiente está configurada. Faça as mudanças necessárias no código no ambiente local:

1. No GitHub, acesse a página principal do seu repositório bifurcado.

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

2. Verifique se você está na ramificação dev.

3. Para abrir o arquivo modules/deploy/dataplex.tf para edição, acesse-o.

4. Na linha 19, mude o rótulo the_environment para environment.

5. Adicione uma mensagem de commit na parte de baixo da página, como "modificando rótulo", e selecione Criar nova ramificação para esse commit e iniciar uma solicitação de pull.

6. Clique em Propor alterações.

7. Na página a seguir, clique em Criar solicitação de pull para abrir uma nova solicitação com sua alteração na ramificação dev.

   Depois que a solicitação de pull é aberta, um job do Cloud Build é iniciado automaticamente.

8. Clique em Mostrar todas as verificações e aguarde a verificação ficar verde. Não mescle sua solicitação de envio ainda. A mesclagem é feita em uma etapa posterior do tutorial.

9. Clique em Detalhes para conferir mais informações, incluindo a saída de terraform plan no link Conferir mais detalhes no Google Cloud Build.

O job do Cloud Build executou o pipeline definido no arquivo cloudbuild.yaml. Esse pipeline tem comportamentos diferentes, dependendo do branch que está sendo buscado. A construção verifica se a variável $BRANCH_NAME corresponde a alguma pasta do ambiente. Nesse caso, o Cloud Build executa terraform plan para esse ambiente. Caso contrário, ele executa terraform plan para todos os ambientes, de modo a garantir que a alteração proposta seja apropriada para todos eles. Se a execução de algum desses planos falhar, a compilação falhará.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.9.8'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFORM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

Da mesma forma, o comando terraform apply é executado para ramificações do ambiente, mas é completamente ignorado em qualquer outro caso. Nesta seção, como você enviou uma mudança de código para uma nova ramificação, nenhuma implantação de infraestrutura foi aplicada ao projeto do Google Cloud .

- id: 'tf apply'
  name: 'hashicorp/terraform:1.9.8'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an official environment."
        echo "*******************************************************************************"
      fi

Aplicar o sucesso da execução do Cloud Build antes de mesclar ramificações

Para garantir que as mesclagens só sejam aplicadas quando as respectivas execuções do Cloud Build forem bem-sucedidas, siga estas etapas:

1. No GitHub, acesse a página principal do seu repositório bifurcado.

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

2. No nome do repositório, clique em Configurações.

3. No menu à esquerda, clique em Ramificações.

4. Em Regras de proteção de ramificação, clique em Adicionar regra.

5. Em Padrão de nome de ramificação, digite dev.

6. Na seção Proteger ramificações correspondentes, selecione Exigir que as verificações de status sejam aprovadas antes da mesclagem.

7. Pesquise o nome do gatilho do Cloud Build criado anteriormente.

8. Clique em Criar.

9. Repita as etapas 3 a 7, definindo Padrão de nome de ramificação como prod.

Essa configuração é importante para proteger as ramificações dev e prod. Isso significa que os commits precisam ser enviados para outra ramificação antes de serem mesclados à ramificação protegida. Neste tutorial, a proteção exige que a execução do Cloud Build seja bem-sucedida para que a mesclagem seja permitida.

Promover mudanças no ambiente de desenvolvimento

Há uma solicitação de pull aguardando para ser mesclada. É hora de aplicar o estado que você quer ao seu ambiente dev.

1. No GitHub, acesse a página principal do seu repositório bifurcado.

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

2. Abaixo do nome do repositório, clique em Solicitações de pull.

3. Clique na solicitação de pull que você acabou de criar.

4. Clique em Mesclar solicitação de pull e em Confirmar mesclagem.

5. Verifique se um novo Cloud Build foi acionado:

   Acessar a página do Cloud Build

6. Abra a compilação e verifique os registros. Ele vai mostrar todos os recursos que o Terraform está criando e gerenciando.

Promover mudanças no ambiente de produção

Agora que você testou totalmente seu ambiente de desenvolvimento, pode promover seu código para regras de qualidade de dados para produção.

1. No GitHub, acesse a página principal do seu repositório bifurcado.

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

2. Abaixo do nome do repositório, clique em Solicitações de pull.

3. Clique em Nova solicitação de pull.

4. Para Repositório base, selecione seu repositório bifurcado.

5. Para Base, selecione prod no seu repositório base. Para Comparar, selecione dev.

6. Clique em Criar solicitação de pull.

7. Para Título, digite um título como Changing label name e clique em Criar solicitação de pull.

8. Revise as alterações propostas, incluindo os detalhes do terraform plan do Cloud Build e clique em Mesclar solicitação de pull.

9. Clique em Confirmar mesclagem.

10. No console do Google Cloud , abra a página Histórico de builds para conferir o progresso da aplicação das alterações no ambiente de produção:

    Acessar a página do Cloud Build

Você configurou regras de qualidade de dados gerenciadas usando o Terraform e o Cloud Build.

Limpar

Depois de concluir este tutorial, limpe os recursos que você criou no Google Cloud para não receber cobranças no futuro.

Excluir o projeto

Cuidado: a exclusão de um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto atual para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos nele.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um ID do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja explorar várias arquiteturas, tutoriais e guias de início rápido, a reutilização de projetos pode evitar que você exceda limites da cota.

1. No console Google Cloud , acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir o repositório do GitHub

Para evitar o bloqueio de novas solicitações de pull no repositório do GitHub, exclua as regras de proteção da ramificação:

1. No GitHub, acesse a página principal do repositório bifurcado.
2. No nome do repositório, clique em Configurações.
3. No menu à esquerda, clique em Ramificações.
4. Na seção Regras de proteção da ramificação, clique no botão Excluir das linhas dev e prod.

Se preferir, desinstale completamente o app Cloud Build do GitHub:

1. No GitHub, acesse a página de aplicativos do GitHub.

2. Na guia Apps instalados do GitHub, clique em Configurar na linha Cloud Build. Em seguida, na seção Zona de perigo, clique no botão Desinstalar na linha Desinstalar o Google Cloud Builder.

   Na parte superior da página, uma mensagem é exibida: Tudo pronto. Um job foi colocado na fila para desinstalar o Google Cloud Build.

3. Na guia Apps autorizados do GitHub, clique no botão Revogar na linha Google Cloud Build e em Entendo, revogar acesso.

Se você não quiser manter o repositório do GitHub, exclua-o:

1. No GitHub, acesse a página principal do seu repositório bifurcado.
2. No nome do repositório, clique em Configurações.
3. Acesse Zona de perigo.
4. Clique em Excluir este repositório e siga as etapas de confirmação.

A seguir

• Saiba mais sobre a qualidade de dados automática.
• Saiba mais sobre DevOps e as práticas recomendadas de DevOps.
• Consulte o Cloud Foundation Toolkit para mais modelos do Terraform.