Esta página se ha traducido con Cloud Translation API.

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

En este tutorial se explica cómo gestionar las reglas de calidad de los datos de Dataplex Universal Catalog como código con Terraform, Cloud Build y GitHub.

Hay muchas opciones diferentes de reglas de calidad de los datos disponibles para definir y medir la calidad de los datos. Si automatizas el proceso de implementar reglas de calidad de los datos como parte de tu estrategia de gestión de infraestructuras, te aseguras de que los datos se sometan de forma constante y predecible a las reglas que les asignes.

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

El control de versiones también es una práctica recomendada importante de DevOps. Gestionar tus reglas de calidad de los datos como código te proporciona versiones de tus 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 las páginas Información general sobre Terraform en Google Cloud y Cloud Build.

Arquitectura

Para entender cómo usa este tutorial Cloud Build para gestionar las ejecuciones de Terraform, consulta el siguiente diagrama de arquitectura. Ten en cuenta que usa ramas de GitHub (dev y prod) para representar entornos reales.

Infraestructura con entornos de desarrollo y producción.

El proceso comienza cuando insertas código de Terraform en la rama dev o prod. En este caso, Cloud Build activa y, a continuación, aplica manifiestos de Terraform para conseguir el estado que quieras en el entorno correspondiente. Por otro lado, cuando insertas código de Terraform en cualquier otra rama (por ejemplo, en una rama de función), Cloud Build se ejecuta para ejecutar terraform plan, pero no se aplica nada a ningún entorno.

Lo ideal es que los desarrolladores o los operadores hagan propuestas de infraestructura a las ramas no protegidas y, a continuación, las envíen mediante solicitudes de extracción. La aplicación de GitHub para Cloud Build, que se explica más adelante en este tutorial, activa automáticamente las tareas de compilación y vincula los informes de terraform plan a estas solicitudes de extracción. De esta forma, puedes hablar y revisar los posibles cambios con los colaboradores y añadir confirmaciones de seguimiento antes de que los cambios se combinen en la rama base.

Si no hay ningún problema, primero debes combinar los cambios en la rama dev. Esta combinación activa un despliegue de infraestructura en el entorno dev, lo que te permite probarlo. Una vez que hayas probado lo que se ha implementado y estés seguro de que funciona correctamente, debes combinar la rama dev con la rama prod para activar la instalación de la infraestructura en el entorno de producción.

Objetivos

Configura tu repositorio de GitHub.
Configura Terraform para almacenar el estado en un segmento de Cloud Storage.
Concede permisos a tu cuenta de servicio de Cloud Build.
Conecta Cloud Build a tu repositorio de GitHub.
Establece reglas de calidad de los datos de Dataplex Universal Catalog.
Cambia la configuración de tu entorno en una rama de función y haz pruebas.
Promocionar los cambios al entorno de desarrollo.
Promociona los cambios al entorno de producción.

Costes

En este documento, se utilizan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

Cuando termines las tareas que se describen en este documento, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpiar.

Antes de empezar

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.

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 (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

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 (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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.
En Cloud Shell, obtén el ID del proyecto que acabas de seleccionar:
```
gcloud config get-value project
```
Si este comando no devuelve el ID del proyecto, configura Cloud Shell para que use tu proyecto. Sustituye PROJECT_ID por el ID de tu proyecto.
```
gcloud config set project PROJECT_ID
```

Habilita las APIs necesarias:

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

Este paso puede tardar unos minutos en completarse.

Si nunca has usado Git en Cloud Shell, configúralo con tu nombre y tu 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 creas en Cloud Shell.

Configurar un repositorio de GitHub

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

La rama dev contiene los últimos cambios que se aplican al entorno de desarrollo.
La rama prod contiene los últimos cambios que se aplican al entorno de producción.

Con esta infraestructura, siempre puedes consultar el repositorio para saber qué configuración se espera en cada entorno y proponer nuevos cambios fusionándolos primero en el entorno dev. A continuación, puedes promover los cambios combinando la rama dev con la rama prod.

Para empezar, crea una bifurcación del repositorio terraform-google-dataplex-auto-data-quality.

En GitHub, ve a https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git.
Haz clic en Bifurcar.

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

En Cloud Shell, clona el siguiente repositorio bifurcado:

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

Haz los cambios siguientes:

GITHUB_USERNAME: tu nombre de usuario de GitHub

Crea las ramas dev y prod:

git checkout -b prod
git checkout -b dev

El código de este repositorio se estructura 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 fases de madurez, desarrollo y producción, respectivamente.
La carpeta modules/ contiene módulos de Terraform insertados. Estos módulos representan agrupaciones lógicas de recursos relacionados y se usan para compartir código en diferentes entornos. El módulo modules/deploy/ representa una plantilla de un despliegue y se reutiliza en diferentes entornos de despliegue.
En modules/deploy/:
- La carpeta rule/ contiene yaml archivos con reglas de calidad de los datos. Un archivo representa un conjunto de reglas de calidad de los datos de una tabla. Este archivo se usa en entornos dev y prod.
- La carpeta schemas/ contiene el esquema de la tabla de BigQuery implementada en esta infraestructura.
- El archivo bigquery.tf contiene la configuración de las tablas de BigQuery creadas en esta implementación.
- El archivo dataplex.tf contiene un análisis de datos de Dataplex Universal Catalog para la calidad de los datos. Este archivo se usa junto con rules_file_parsing.tf para leer las 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, como la forma de realizar tareas basadas en un conjunto de pasos. Este archivo especifica una ejecución condicional en función de la rama de la que Cloud Build obtiene el código. Por ejemplo:
- En las ramas dev y prod, se siguen estos pasos:
  1. terraform init
  2. terraform plan
  3. terraform apply
- En cualquier otra rama, se ejecutan los siguientes pasos:
  1. terraform init para todas las environments subcarpetas
  2. terraform plan para todas las environments subcarpetas

Para asegurarnos de que los cambios propuestos son adecuados para todos los entornos, se ejecutan terraform init y terraform plan en todos los entornos. Antes de combinar la solicitud de extracción, puedes revisar los planes para asegurarte de que no se concede acceso a una entidad no autorizada, por ejemplo.

Configurar Terraform para almacenar el estado en segmentos de Cloud Storage

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

Para ayudarte a evitar estos problemas, en esta sección se configura un estado remoto que apunta a un segmento de Cloud Storage. El estado remoto es una función de los backends y, en este tutorial, se configura 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"
  }
}

Hay un archivo backend.tf independiente en cada uno de los entornos dev y prod. Se recomienda usar un segmento de Cloud Storage diferente para cada entorno.

En los pasos siguientes, creará dos depósitos de Cloud Storage para dev y prod, y cambiará algunos archivos para que apunten a sus nuevos depósitos y a su proyectoGoogle Cloud .

En Cloud Shell, crea los dos segmentos 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}

Para conservar el historial de tus implementaciones, habilita la gestión de versiones de objetos:
```
gcloud storage buckets update ${DEV_BUCKET} --versioning
gcloud storage buckets update ${PROD_BUCKET} --versioning
```
Si habilitas la gestión de versiones de objetos, aumentarán los costes de almacenamiento, que puedes reducir configurando la gestión del ciclo de vida de los objetos para eliminar las versiones antiguas.

En cada entorno, en los archivos main.tf y backend.tf , sustituye PROJECT_ID por el ID del proyecto:

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 tengas que añadir dos comillas ("") después de sed -i, como se indica a continuación:

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

Comprueba si se han actualizado todos los archivos:

git status

A continuación, se muestra un ejemplo de resultado:

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")

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, debes autenticarte para enviar los cambios anteriores.

Conceder permisos a tu 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 gestionar recursos de Google Cloud , debes concederle el acceso adecuado a tu proyecto. Para simplificar las cosas, en este tutorial se concede acceso de editor de proyectos. Sin embargo, cuando el rol de editor de proyectos tiene un permiso amplio, en los entornos de producción, debes seguir las prácticas recomendadas de seguridad de TI de tu empresa, que suelen proporcionar acceso con los mínimos privilegios.

En Cloud Shell, recupera el correo de la cuenta de servicio de Cloud Build de tu proyecto:

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

Concede el acceso necesario a tu cuenta de servicio de Cloud Build:

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

Conectar Cloud Build directamente a tu repositorio de GitHub

En esta sección se describe cómo instalar la aplicación de GitHub para Cloud Build. Esta instalación te permite conectar tu repositorio de GitHub con tuGoogle Cloud proyecto para que Cloud Build pueda aplicar automáticamente tus manifiestos de Terraform cada vez que crees una rama o insertes código en GitHub.

En los pasos siguientes se explica cómo instalar la aplicación solo para el repositorio terraform-google-dataplex-auto-data-quality, pero puedes instalarla para más repositorios o para todos.

En GitHub Marketplace, ve a la página de la aplicación Cloud Build.
- Si es la primera vez que configuras una aplicación en GitHub, haz clic en Configurar con Google Cloud Build en la parte inferior de la página. A continuación, haz clic en Grant this app access to your GitHub account (Conceder acceso a esta aplicación a tu cuenta de GitHub).
- Si no es la primera vez que configuras una aplicación en GitHub, haz clic en Configurar acceso. Se abrirá la página Aplicaciones de tu cuenta personal.
En la fila de Cloud Build, haga clic en Configurar.
Selecciona Solo repositorios seleccionados y, a continuación, terraform-google-dataplex-auto-data-quality para conectarte al repositorio.
Haz clic en Guardar o en Instalar. La etiqueta del botón cambia en función de tu flujo de trabajo. Se te redirigirá a Google Cloud para continuar con la instalación.
Inicia sesión con tu cuenta de Google Cloud . Si se te solicita, autoriza la integración de Cloud Build con GitHub.
En la página Cloud Build, selecciona tu proyecto. Aparecerá un asistente.
En la sección Select repository (Seleccionar repositorio), selecciona tu cuenta de GitHub y el repositorio terraform-google-dataplex-auto-data-quality.
Si acepta los términos y condiciones, marque la casilla y haga clic en Conectar.
En la sección Crear un activador, haz clic en Crear un activador:
1. Añade un nombre de activador, como push-to-branch. Anota el nombre de este activador, ya que 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 aplicación de GitHub para Cloud Build está configurada y tu repositorio de GitHub está vinculado a tu proyecto Google Cloud . Los cambios en el repositorio de GitHub activan ejecuciones de Cloud Build, que informan de los resultados a GitHub mediante comprobaciones de GitHub.

Cambiar la configuración del entorno en una nueva rama de funciones

Ya tienes configurada la mayor parte de tu entorno. Haz los cambios de código necesarios en tu entorno local:

En GitHub, ve a la página principal del repositorio bifurcado.

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

Asegúrate de que estás en la rama dev.
Para abrir el archivo y editarlo, ve al archivo modules/deploy/dataplex.tf.
En la línea 19, cambia la etiqueta the_environment por environment.
Añade un mensaje de confirmación en la parte inferior de la página, como "modifying label" (modificar etiqueta), y selecciona Create a new branch for this commit and start a pull request (Crea una rama para esta confirmación e inicia una solicitud de extracción).
Haga clic en Proponer cambios.
En la página siguiente, haz clic en Crear solicitud de extracción para abrir una nueva solicitud de extracción con el cambio que has hecho en la rama dev.

Una vez que se abre la solicitud de extracción, se inicia automáticamente un trabajo de Cloud Build.
Haz clic en Mostrar todas las comprobaciones y espera a que la comprobación se ponga en verde. No combines tu solicitud de extracción todavía. La combinación se realiza en un paso posterior del tutorial.
Haz clic en Detalles para ver más información, incluida la salida de terraform plan en el enlace Ver más detalles sobre Google Cloud Build.

Ten en cuenta que el trabajo de Cloud Build ha ejecutado la canalización definida en el archivo cloudbuild.yaml. Esta canalización tiene comportamientos diferentes en función de la rama que se obtenga. La compilación comprueba 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 en todos los entornos para asegurarse de que el cambio propuesto sea adecuado para todos ellos. Si no se puede ejecutar alguno de estos planes, la compilación fallará.

- 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

Del mismo modo, el comando terraform apply se ejecuta en las ramas del entorno, pero se ignora por completo en cualquier otro caso. En esta sección, has enviado un cambio de código a una rama nueva, por lo que no se han aplicado despliegues de infraestructura a tu proyecto 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

Exigir que las compilaciones de Cloud Build se ejecuten correctamente antes de combinar ramas

Para asegurarse de que las combinaciones solo se puedan aplicar cuando las ejecuciones de Cloud Build correspondientes se hayan completado correctamente, siga estos pasos:

En GitHub, ve a la página principal del repositorio bifurcado.

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

Debajo del nombre del repositorio, haz clic en Settings (Configuración).
En el menú de la izquierda, haga clic en Sucursales.
En Reglas de protección de ramas, haz clic en Añadir regla.
En Patrón de nombre de rama, escribe dev.
En la sección Proteger ramas coincidentes, selecciona Requerir que se superen las comprobaciones de estado antes de combinar.
Busca el nombre del activador de Cloud Build que hayas creado anteriormente.
Haz clic en Crear.
Repite los pasos del 3 al 7 y asigna el valor prod a Patrón de nombre de rama.

Esta configuración es importante para proteger las ramas dev y prod. Es decir, los commits deben enviarse primero a otra rama y, solo entonces, se pueden combinar con la rama protegida. En este tutorial, la protección requiere que la ejecución de Cloud Build se realice correctamente para que se permita la combinación.

Promocionar cambios en el entorno de desarrollo

Tienes una solicitud de extracción pendiente de combinación. Es el momento de aplicar el estado que quieras a tu entorno dev.

En GitHub, ve a la página principal del repositorio bifurcado.

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

Debajo del nombre del repositorio, haz clic en Pull requests (Solicitudes de extracción).
Haz clic en la solicitud de extracción que acabas de crear.
Haz clic en Combinar solicitud de extracción y, a continuación, en Confirmar combinación.
Comprueba que se haya activado una nueva compilación de Cloud Build:

Ir a la página Cloud Build
Abre la compilación y consulta los registros. Se mostrarán todos los recursos que Terraform está creando y gestionando.

Promocionar cambios en el entorno de producción

Ahora que has probado completamente tu entorno de desarrollo, puedes promover tu código para las reglas de calidad de los datos a producción.

En GitHub, ve a la página principal del repositorio bifurcado.

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

Debajo del nombre del repositorio, haz clic en Pull requests (Solicitudes de extracción).
Haz clic en Nueva solicitud de extracción.
En repositorio base, selecciona el repositorio que acabas de bifurcar.
En base, selecciona prod de tu repositorio base. Para comparar, selecciona dev.
Haz clic en Crear solicitud de extracción.
En título, escribe un título como Changing label name y, a continuación, haz clic en Crear solicitud de extracción.
Revisa los cambios propuestos, incluidos los terraform plan detalles de Cloud Build, y haz clic en Combinar solicitud de extracción.
Haz clic en Confirmar combinación.
En la Google Cloud consola, abre la página Historial de compilaciones para ver cómo se aplican los cambios al entorno de producción:

Ir a la página Cloud Build

Has configurado correctamente reglas de calidad de los datos que se gestionan con Terraform y Cloud Build.

Limpieza

Cuando hayas terminado el tutorial, elimina los recursos que has creado enGoogle Cloud para que no se te facturen en el futuro.

Eliminar el proyecto

Precaución: Eliminar un proyecto tiene los siguientes efectos:

Se elimina todo el contenido del proyecto. Si has usado un proyecto que ya existía para las tareas de este documento, cuando lo elimines, también se eliminará cualquier otro trabajo que hayas realizado en él.
Se pierden los IDs de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID de proyecto personalizado que quieras usar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, elimina los recursos seleccionados dentro del proyecto en lugar de eliminar todo el proyecto.

Si tienes previsto consultar varias arquitecturas, tutoriales o guías de inicio rápido, reutilizar los proyectos puede ayudarte a no superar los límites de cuota de proyectos.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Eliminar el repositorio de GitHub

Para evitar que se bloqueen nuevas solicitudes de extracción en tu repositorio de GitHub, puedes eliminar tus reglas de protección de ramas:

En GitHub, ve a la página principal del repositorio bifurcado.
Debajo del nombre del repositorio, haz clic en Settings (Configuración).
En el menú de la izquierda, haga clic en Sucursales.
En la sección Reglas de protección de ramas, haz clic en el botón Eliminar de las filas dev y prod.

Si quieres, puedes desinstalar por completo la aplicación Cloud Build de GitHub:

En GitHub, ve a la página Aplicaciones de GitHub.
En la pestaña Aplicaciones de GitHub instaladas, haz clic en Configurar en la fila Cloud Build. A continuación, en la sección Zona de peligro, haga clic en el botón Desinstalar de la fila Desinstalar Google Cloud Builder.

En la parte superior de la página, verás el mensaje "Todo listo. Se ha puesto en cola una tarea para desinstalar Google Cloud Build."
En la pestaña Aplicaciones de GitHub autorizadas, haz clic en el botón Revocar de la fila Google Cloud Build y, a continuación, en Entiendo, revocar acceso.

Si no quieres conservar tu repositorio de GitHub, elimínalo:

En GitHub, ve a la página principal del repositorio bifurcado.
Debajo del nombre del repositorio, haz clic en Settings (Configuración).
Ve a Zona de peligro.
Haz clic en Eliminar este repositorio y sigue los pasos de confirmación.

Siguientes pasos

Consulta información sobre la calidad de los datos automática.
Consulta más información sobre DevOps y las prácticas recomendadas de DevOps.
Consulta Cloud Foundation Toolkit para ver más plantillas de Terraform.

Gestionar reglas de calidad de los datos como código con Terraform Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Arquitectura

Objetivos

Costes

Antes de empezar

Configurar un repositorio de GitHub

Configurar Terraform para almacenar el estado en segmentos de Cloud Storage

Conceder permisos a tu cuenta de servicio de Cloud Build

Conectar Cloud Build directamente a tu repositorio de GitHub

Cambiar la configuración del entorno en una nueva rama de funciones

Exigir que las compilaciones de Cloud Build se ejecuten correctamente antes de combinar ramas

Promocionar cambios en el entorno de desarrollo

Promocionar cambios en el entorno de producción

Limpieza

Eliminar el proyecto

Eliminar el repositorio de GitHub

Siguientes pasos

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