Administra reglas de calidad de los datos como código con Terraform

En este instructivo, se explica cómo administrar Dataplex de calidad de los datos como código Terraform, Cloud Build y GitHub.

Existen muchas opciones de reglas de calidad de datos para definir y definir medir la calidad de tus datos. Cuando automatizas el proceso de implementación las reglas de calidad de los datos como parte de una estrategia más amplia de administración te aseguras de que tus datos estén sujetos a las reglas de manera coherente y predecible que le asignes.

Si tienes diferentes versiones de un conjunto de datos para varios entornos, como los entornos dev y prod, Terraform proporciona una forma confiable de asignar reglas de calidad de datos a versiones de conjuntos de datos específicas del entorno.

El control de versión también es una práctica recomendada importante para DevOps. Administrar tus reglas de calidad de los datos como código te proporciona versiones de las reglas de calidad de los datos que están disponibles en tu historial de GitHub. Terraform también puede guardar su estado en Cloud Storage, que puede almacenar versiones anteriores del archivo de estado.

Para obtener más información sobre Terraform y Cloud Build, consulta Descripción general de Terraform en Google Cloud y Cloud Build.

Arquitectura

Para comprender cómo este instructivo usa Cloud Build para administrar las ejecuciones de Terraform, considera el siguiente diagrama de arquitectura. Ten en cuenta que se usan ramas de GitHub (dev y prod) para representar entornos reales.

Nota: Para que sea más simple, en este instructivo, solo se implementan dev y prod entornos de prueba. Puedes extender este comportamiento para implementarlo en más entornos y crear proyectos bajo una jerarquía de organización si es necesario.

El proceso se inicia cuando envías código de Terraform a la rama dev o prod. En esta situación, Cloud Build se activa y aplica los manifiestos de Terraform para lograr el estado que deseas en el entorno respectivo. Por otro lado, cuando envías código de Terraform a cualquier otra rama (por ejemplo, a una rama de características), Cloud Build se activa para ejecutar terraform plan, pero no se aplica nada a ningún entorno.

Lo ideal es que los operadores o desarrolladores deban hacer propuestas de infraestructura a ramas no protegidas y, luego, enviarlas a través de solicitudes de extracción. La app de GitHub de Cloud Build, que se detalla más adelante en este instructivo, activa de forma automática los trabajos de compilación y vincula los informes terraform plan a estas solicitudes de extracción. De esta manera, puedes analizar y revisar los posibles cambios con los colaboradores y agregar confirmaciones de seguimiento antes de que los cambios se combinen en la rama base.

Si no surgen problemas, primero se deben combinar los cambios en la rama dev. Esta combinación activa una implementación de infraestructura para el entorno dev, lo que te permite probar este entorno. Después de realizar las pruebas y asegurarte de que la implementación es correcta, debes combinar la rama dev con la rama prod para activar la instalación de la infraestructura en el entorno de producción.

Objetivos

• Configurar tu repositorio de GitHub.
• Configurar Terraform para almacenar el estado en un bucket de Cloud Storage.
• Otorgar permisos a tu cuenta de servicio de Cloud Build.
• Conectar Cloud Build a tu repositorio de GitHub.
• Establecer reglas de calidad de datos de Dataplex
• Cambiar la configuración del entorno en una rama de funciones y realizar una prueba
• Promover los cambios en el entorno de desarrollo.
• Promover los cambios en el entorno de producción.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• BigQuery
• Cloud Build
• Cloud Storage
• Compute Engine
• Dataplex

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Requisitos previos

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

   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

3. Make sure that billing is enabled for your Google Cloud project.

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

   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

5. Make sure that billing is enabled for your Google Cloud project.

6. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

7. En Cloud Shell, obtén el ID del proyecto que acabas de seleccionar:

   gcloud config get-value project

   Si este comando no muestra el ID del proyecto, configura Cloud Shell para que use tu proyecto. Reemplaza PROJECT_ID por tu proyecto. ID.

   gcloud config set project PROJECT_ID

8. Habilita las API necesarias:

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

   Este paso puede tardar unos minutos en finalizar.
9. Si nunca usaste Git en Cloud Shell, configúralo con tu nombre y dirección de correo electrónico:

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

   Git usa esta información para identificarte como el autor de las confirmaciones que crear en Cloud Shell.

Configura tu repositorio de GitHub

En este instructivo, usarás un único repositorio de Git para definir tu infraestructura de nube. Debes tener diferentes ramas que correspondan a diferentes entornos para organizar esta infraestructura:

• La rama dev contiene los cambios más recientes que se aplican al entorno de desarrollo.
• La rama prod contiene los cambios más recientes que se aplican al entorno de producción.

Con esta infraestructura, siempre se puede hacer referencia al repositorio a fin de saber qué configuración se espera en cada entorno y combinar cambios nuevos con el entorno dev para proponerlos. Luego, debes combinar la rama dev con la rama posterior prod para promover los cambios.

Para comenzar, bifurca terraform-google-dataplex-auto-data-quality en un repositorio de confianza.

1. En GitHub, dirígete a https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git.

2. Haz clic en Fork.

   Ahora tienes una copia del repositorio terraform-google-dataplex-auto-data-quality con archivos de origen.

3. En Cloud Shell, reemplaza YOUR_GITHUB_USERNAME por tu nombre de usuario de GitHub para clonar este repositorio bifurcado:

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

4. Crea las ramas dev y prod:

   git checkout -b prod
   git checkout -b dev
   

El código de este repositorio está estructurado de la siguiente manera:

• La carpeta environments/ contiene subcarpetas que representan entornos, como dev y prod, que proporcionan una separación lógica entre las cargas de trabajo en diferentes etapas de madurez, desarrollo y producción, respectivamente.

• La carpeta modules/ contiene módulos de Terraform intercalados. Estos módulos representan agrupaciones lógicas de recursos relacionados y se usan para compartir código entre diferentes entornos. En este caso, el módulo modules/deploy/ representa un plantilla de un Deployment y se reutiliza en diferentes entornos de prueba.

• Dentro de modules/deploy/:

  • La carpeta rule/ contiene archivos yaml que contienen reglas de calidad de los datos. Un archivo representa un conjunto de datos de calidad para una tabla. Este archivo se usa en entornos dev y prod.

  • La carpeta schemas/ contiene el esquema de la tabla de BigQuery que se implementó en esta infraestructura.

  • El archivo bigquery.tf contiene la configuración de las tablas de BigQuery que se crearon en esta implementación.

  • El archivo dataplex.tf contiene un análisis de datos de Dataplex para la calidad de los datos. Este archivo se usa junto con rules_file_parsing.tf para leer reglas de calidad de los datos de un archivo yaml en el entorno.

• El archivo cloudbuild.yaml es un archivo de configuración de compilación que contiene instrucciones para Cloud Build, por ejemplo, cómo realizar tareas en función de un conjunto de pasos. Este archivo especifica una ejecución condicional según la rama de la cual Cloud Build recupera el código, por ejemplo:

  • En las ramas dev y prod, se ejecutan los siguientes pasos:

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

  • Para cualquier otra rama, se ejecutan los siguientes pasos:

    1. terraform init para todas las subcarpetas environments
    2. terraform plan para todas las subcarpetas environments

Para garantizar que los cambios propuestos sean adecuados para cada entorno, terraform init y terraform plan se ejecutan para todos los entornos. Antes combinando la solicitud de extracción, puedes revisar los planes para asegurarte de que el acceso que no se otorgue a una entidad no autorizada, por ejemplo.

Configura Terraform para almacenar el estado en buckets de Cloud Storage

De forma predeterminada, Terraform almacena el estado de manera local en un archivo llamado terraform.tfstate. Esta configuración predeterminada puede dificultar el uso de Terraform para los equipos, en especial cuando muchos usuarios ejecutan Terraform al mismo tiempo y cada máquina tiene su propia comprensión de la infraestructura actual.

Para ayudarte a evitar tales problemas, esta sección configura un estado remoto que apunta a un bucket de Cloud Storage. El estado remoto es una función de backends En este instructivo, está configurada en el archivo 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"
  }
}

Existe un archivo backend.tf independiente en cada uno de los entornos dev y prod. Se considera una práctica recomendada usar una distinta bucket de Cloud Storage para cada entorno.

En los siguientes pasos, crearás dos buckets de Cloud Storage para dev. y prod, y cambia algunos archivos para que apunten a tus buckets nuevos proyecto de Google Cloud.

1. En Cloud Shell, crea los dos buckets de 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. Habilita el control de versiones de objetos para mantener el historial de tus implementaciones:

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

   Habilitar el control de versiones de objetos aumenta los costos de almacenamiento, lo cual se puede mitigar si configuras la Administración del ciclo de vida de los objetos para que borre versiones de estado antiguas.

3. Reemplaza el marcador de posición PROJECT_ID por el proyecto. ID de los archivos main.tf y backend.tf de cada entorno:

   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
   

   En OS X o macOS, es posible que debas agregar dos comillas ("") después de sed -i de la siguiente manera:

   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. Verifica si todos los archivos se actualizaron:

   git status
   

   El resultado obtenido se verá así:

   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. Confirma y envía los cambios:

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

   Según tu configuración de GitHub, tendrás que autenticarte para enviar los cambios anteriores.

Otorga permisos a la cuenta de servicio de Cloud Build

Para permitir que la cuenta de servicio de Cloud Build ejecute secuencias de comandos de Terraform con el objetivo de administrar recursos de Google Cloud, debes otorgarle el acceso adecuado a tu proyecto. Para hacerlo más simple, en este instructivo, se otorga acceso de editor de proyectos. Sin embargo, cuando la función de editor de proyectos tiene un permiso de amplio rango, en entornos de producción debes seguir las prácticas recomendadas de seguridad de TI de tu empresa, para lo cual, por lo general, debes proporcionar el acceso de mínimo privilegio.

1. En Cloud Shell, recupera el correo electrónico de la cuenta de servicio de Cloud Build de tu proyecto:

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

2. Otorga el acceso requerido a tu cuenta de servicio de Cloud Build:

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

Conecta Cloud Build directamente a un repositorio de GitHub

En esta sección, se muestra cómo instalar el App de GitHub de Cloud Build. Esta instalación te permite conectar tu repositorio de GitHub a tu proyecto de Google Cloud para que Cloud Build pueda aplicar tus manifiestos de Terraform cada vez que crees una nueva rama o envíes código a GitHub.

En los siguientes pasos, se proporcionan instrucciones a fin de instalar la app solo para el repositorio terraform-google-dataplex-auto-data-quality, pero puedes elegir instalarla en más repositorios o en todos.

1. En GitHub Marketplace, ve a la página de la app de Cloud Build.

   • Si es la primera vez que configuras una app en GitHub, haz clic en Configurar con Google Cloud Build en la parte inferior de la página y, a continuación, haz clic en Otorga a esta aplicación acceso a tu cuenta de GitHub.
   • Si no es la primera vez que configuras una app en GitHub, haz clic en Configurar acceso. Se abrirá la página Aplicaciones de tu cuenta personal.

2. Haz clic en Configurar en la fila de Cloud Build.

3. Selecciona Solo repositorios seleccionados y, luego, selecciona terraform-google-dataplex-auto-data-quality para conectarte al repositorio.

4. Haz clic en Guardar o Instalar, y la etiqueta del botón cambia según el flujo de trabajo. Se te redireccionará a Google Cloud para continuar con la instalación.

5. Accede con tu cuenta de Google Cloud. Si se te solicita, autoriza la integración de Cloud Build con GitHub.

6. En la página Cloud Build, selecciona el proyecto. Aparecerá un asistente.

7. En la sección Selecciona un repositorio, selecciona tu cuenta de GitHub y el repositorio terraform-google-dataplex-auto-data-quality.

8. Si aceptas los Términos y Condiciones, selecciona la casilla de verificación y, luego, haz clic en Conectar.

9. En la sección Crear un activador, haz clic en Crear un activador:

   1. Agrega un nombre de activador, como push-to-branch. Toma nota de este nombre de activador porque lo necesitarás más adelante.
   2. En la sección Evento, selecciona Enviar a una rama.
   3. En la sección Fuente, selecciona .* en el campo Rama.
   4. Haz clic en Crear.

La app de GitHub de Cloud Build ya está configurada y el repositorio de GitHub está vinculado al proyecto de Google Cloud. Desde ahora, los cambios en el repositorio de GitHub activan ejecuciones de Cloud Build, que informan los resultados a GitHub mediante las Verificaciones de GitHub.

Cambia la configuración de tu entorno en una nueva rama de características

En este punto, ya tienes la mayor parte de tu entorno configurado. Por lo tanto, es hora de hacer algunos cambios en el código de tu entorno local.

1. En GitHub, dirígete a la página principal del repositorio bifurcado.

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

2. Asegúrate de estar en la rama dev.

3. Para abrir el archivo y editarlo, ve al archivo modules/deploy/dataplex.tf.

4. En la línea 19, cambia la etiqueta the_environment a environment.

5. Agrega un mensaje de confirmación en la parte inferior de la página, como “modificación de la etiqueta”, y selecciona Crear una rama nueva para esta confirmación y comenzar una solicitud de extracción.

6. Haz clic en Proponer cambios.

7. En la página siguiente, haz clic en Crear solicitud de extracción para abrir una nueva solicitud de extracción con tu cambio en la rama dev.

   Una vez que tu solicitud de extracción esté abierta, se inicia de forma automática un trabajo de Cloud Build.

8. Haz clic en Show all checks y espera a que la marca se vuelva verde. No combines tu solicitud de extracción aún. La combinación se realiza en un paso posterior del instructivo.

9. Haz clic en Detalles (Details) para ver más información, incluido el resultado del terraform plan en el vínculo Ver más detalles de Google Cloud Build.

Ten en cuenta que el trabajo de Cloud Build ejecutó la canalización definida en el archivo cloudbuild.yaml. Como se detalló antes, esta canalización tiene comportamientos diferentes según la rama que se recupera. La compilación verifica si la variable $BRANCH_NAME coincide con alguna carpeta de entorno. Si es así, Cloud Build ejecuta terraform plan para ese entorno. De lo contrario, Cloud Build ejecuta terraform plan para todos los entornos a fin de garantizar que el cambio propuesto sea apropiado en todos ellos. Si alguno de estos planes no se ejecuta, falla la compilación.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.9.5'
  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

De manera similar, el comando terraform apply se ejecuta para las ramas de entorno, pero se ignora por completo en cualquier otro caso. En esta sección, enviaste un cambio de código a una rama nueva, por lo que no se aplicaron implementaciones de infraestructura en el proyecto de Google Cloud.

- id: 'tf apply'
  name: 'hashicorp/terraform:1.9.5'
  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

Fuerza la ejecución exitosa de Cloud Build antes de combinar las ramas

Para garantizar que las combinaciones solo se puedan aplicar cuando las ejecuciones respectivas de Cloud Build sean exitosas, continúa con los siguientes pasos:

1. En GitHub, dirígete a la página principal de tu repositorio bifurcado.

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

2. En el nombre de tu repositorio, haz clic en Configuración.

3. En el menú de la izquierda, haz clic en Ramas.

4. En Reglas de protección de ramas, haz clic en Agregar regla.

5. En Patrón del nombre de la rama, escribe dev.

6. En la sección Proteger ramas coincidentes, selecciona Solicitar verificaciones de estado para que se aprueben antes de realizar la combinación.

7. Busca el nombre del activador de Cloud Build que creaste antes.

8. Haz clic en Crear.

9. Repite los pasos del 3 al 7 y establece el Branch name pattern en prod.

Esta configuración es importante para proteger las ramas dev y prod. Es decir, las confirmaciones primero deben enviarse a otra rama y solo entonces pueden combinarse con la rama protegida. En este instructivo, la protección requiere que la ejecución de Cloud Build sea exitosa para que se permita la combinación.

Promueve los cambios en el entorno de desarrollo

Tienes una solicitud de extracción en espera para combinarse. Es momento de aplicar el estado que deseas en el entorno dev.

1. En GitHub, dirígete a la página principal del repositorio bifurcado.

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

2. Bajo el nombre del repositorio, haz clic en Solicitudes de extracción.

3. Haz clic en la solicitud de extracción que acabas de crear.

4. Haz clic en Combinar solicitud de extracción (Merge pull request) y, luego, en Confirmar combinación.

5. Verifica que se haya activado una nueva Cloud Build:

   Ir a la página Cloud Build

6. Abre la compilación y verifica los registros. Se te mostrarán todos los recursos que Terraform está creando y administrando.

Promueve los cambios en el entorno de producción

Ahora que probaste por completo tu entorno de desarrollo, puedes promover tu código de reglas de calidad de datos a producción.

1. En GitHub, dirígete a la página principal del repositorio bifurcado.

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

2. Bajo el nombre del repositorio, haz clic en Solicitudes de extracción.

3. Haz clic en New pull request.

4. En el repositorio base, selecciona el repositorio recién bifurcado.

5. En base, selecciona prod en tu propio repositorio base. Para comparar, selecciona dev.

6. Haz clic en Create pull request.

7. En título, ingresa un título como Changing label name y, luego, haz clic en Crear solicitud de extracción.

8. Revisa los cambios propuestos, incluidos los detalles del terraform plan de Cloud Build y, luego, haz clic en Combinar solicitud de extracción.

9. Haz clic en Confirmar combinación.

10. En la consola de Google Cloud, abre la página Historial de compilación para ver cómo se aplican los cambios al entorno de producción:

    Ir a la página Cloud Build

Configuraste correctamente las reglas de calidad de los datos que se administran con Terraform y Cloud Build.

Limpia

Una vez que completaste el instructivo, borra los recursos que creaste en Google Cloud a fin de que no se te cobre por ellos en el futuro.

Borra el proyecto

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Borra el repositorio de GitHub

Para evitar bloquear nuevas solicitudes de extracción en tu repositorio de GitHub, puedes borrar las reglas de protección de ramas:

1. En GitHub, dirígete a la página principal de tu repositorio bifurcado.
2. En el nombre de tu repositorio, haz clic en Configuración.
3. En el menú de la izquierda, haz clic en Ramas.
4. En la sección Reglas de protección de ramas, haz clic en el botón Borrar para las filas dev y prod.

De manera opcional, puedes desinstalar por completo la app de Cloud Build de GitHub:

1. En GitHub, ve a la página Aplicaciones de GitHub.

2. En la pestaña Apps de GitHub instaladas, haz clic en Configurar en la fila Cloud Build. Luego, en la sección Zona de peligro, haz clic en el botón Desinstalar en la fila Desinstalar Google Cloud Builder.

   En la parte superior de la página, verás un mensaje que dice "Estás listo. Se puso en cola un trabajo para desinstalar Google Cloud Build”.

3. En la pestaña Authorized GitHub Apps, haz clic en el botón Revocar en la de Google Cloud Build y, luego, Entiendo, revocar el acceso.

Si no deseas conservar tu repositorio de GitHub, haz lo siguiente:

1. En GitHub, ve a la página principal del repositorio bifurcado.
2. En el nombre de tu repositorio, haz clic en Configuración.
3. Ve a Zona de peligro.
4. Haz clic en Borrar este repositorio y sigue los pasos para confirmar.

¿Qué sigue?

• Obtén información sobre la calidad de datos automática.
• Obtén más información sobre DevOps y prácticas recomendadas de DevOps.
• Explora Cloud Foundation Toolkit para obtener más plantillas de Terraform.