Gestisci le regole sulla qualità dei dati come codice con Terraform

Questo tutorial spiega come gestire Dataplex regole sulla qualità dei dati come codice con Terraform, Cloud Build e GitHub.

Sono disponibili molte opzioni diverse per le regole sulla qualità dei dati per definire misurare la qualità dei dati. Quando automatizzi il processo di implementazione delle regole di qualità dei dati nell'ambito della tua strategia di gestione dell'infrastruttura più ampia, assicurati che i dati siano sottoposti in modo coerente e prevedibile alle regole che assegni.

Se hai versioni diverse di un set di dati per più ambienti, ad esempio Ambienti dev e prod, Terraform offre un modo affidabile per assegnare i dati e regole sulla qualità per le versioni specifiche dell'ambiente dei set di dati.

Il controllo delle versioni è anche una best practice importante di DevOps. Gestione le regole sulla qualità dei dati poiché il codice fornisce versioni della qualità dei dati disponibili nella cronologia di GitHub. Terraform può anche salvare il proprio stato in Cloud Storage, che può archiviare le versioni precedenti file di stato.

Per saperne di più su Terraform e Cloud Build, consulta Panoramica di Terraform su Google Cloud e Cloud Build.

Architettura

Per capire in che modo questo tutorial utilizza Cloud Build per gestire Nelle esecuzioni di Terraform, considera il seguente diagramma dell'architettura. Tieni presente che utilizza i branch di GitHub, dev e prod, per rappresentare gli ambienti effettivi.

Infrastruttura con ambienti di sviluppo e produzione.

Il processo si avvia quando esegui il push del codice Terraform sull'oggetto dev o prod ramo. In questo scenario, Cloud Build attiva e quindi applica dei manifest Terraform per ottenere lo stato desiderato nel rispettivo ambiente. D'altra parte, quando esegui il push del codice Terraform in un altro ramo, ad esempio in un ramo di funzionalità, Cloud Build viene eseguito per eseguire terraform plan, ma non viene applicato nulla a nessun ambiente.

Idealmente, gli sviluppatori o gli operatori devono fare proposte di infrastruttura per rami non protetti e poi inviarli tramite richieste di pull. La App GitHub di Cloud Build, di cui abbiamo parlato più avanti in questo tutorial, attiva automaticamente i job di build collega i report terraform plan a queste richieste di pull. In questo modo, puoi discutere e rivedere le potenziali modifiche con i collaboratori e aggiungere commit di follow-up prima che le modifiche vengano unite al ramo base.

Se non vengono sollevati dubbi, devi prima unire le modifiche a dev ramo. Questa unione attiva un deployment dell'infrastruttura nell'ambiente dev , consentendoti di testarlo. Dopo aver testato e di cosa è stato eseguito il deployment, devi unire il ramo dev al Ramo prod per attivare l'installazione dell'infrastruttura in produzione completamente gestito di Google Cloud.

Obiettivi

  • Configura il tuo repository GitHub.
  • Configura Terraform in modo da archiviare lo stato in un bucket Cloud Storage.
  • Concedi le autorizzazioni al tuo account di servizio Cloud Build.
  • Connetti Cloud Build al tuo repository GitHub.
  • Stabilire regole sulla qualità dei dati Dataplex.
  • Modifica la configurazione del tuo ambiente in un ramo di funzionalità ed esegui un test.
  • Promuovere le modifiche all'ambiente di sviluppo.
  • Promuovere le modifiche all'ambiente di produzione.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prerequisiti

  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.

    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.

    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. In Cloud Shell, recupera l'ID del progetto appena selezionato: 
    gcloud config get-value project
     Se questo comando non restituisce l'ID progetto, configura Cloud Shell per utilizzare il tuo progetto. Sostituisci PROJECT_ID con il tuo progetto ID. 
    gcloud config set project PROJECT_ID
  8. Abilita le API richieste: 
    gcloud services enable bigquery.googleapis.com cloudbuild.googleapis.com compute.googleapis.com dataplex.googleapis.com
     Il completamento di questo passaggio potrebbe richiedere alcuni minuti.
  9. Se non hai mai utilizzato Git in Cloud Shell, configuralo con nome e indirizzo email: 
    git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
    Git utilizza queste informazioni per identificarti come autore dei commit che crei in Cloud Shell.

Configurazione del repository GitHub

In questo tutorial, utilizzerai un singolo repository Git per definire il tuo dell'infrastruttura. Puoi orchestrare questa infrastruttura disponendo di diversi rami corrispondenti a diversi ambienti:

  • Il ramo dev contiene le ultime modifiche applicate all'ambiente di sviluppo.
  • Il ramo prod contiene le ultime modifiche applicate all'ambiente di produzione.

Con questa infrastruttura, puoi sempre fare riferimento al repository per sapere quale configurazione è prevista in ogni ambiente e proporre nuove modifiche combinndole prima nell'ambiente dev. Quindi promuovi le modifiche unendo il ramo dev nel ramo prod successivo.

Per iniziare, crea un fork terraform-google-dataplex-auto-data-quality repository Git.

  1. Su GitHub, vai a https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git.

  2. Fai clic su Fork.

    Ora hai una copia di terraform-google-dataplex-auto-data-quality un repository con file di origine.

  3. In Cloud Shell, clona questo repository creato con fork, sostituendo YOUR_GITHUB_USERNAME con il tuo nome utente GitHub:

    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 rami dev e prod:

    git checkout -b prod
git checkout -b dev

Il codice in questo repository è strutturato come segue:

  • La cartella environments/ contiene sottocartelle che rappresentano ambienti, come dev e prod, che forniscono una separazione logica tra i carichi di lavoro nelle diverse fasi di maturità, sviluppo e produzione.

  • La cartella modules/ contiene moduli Terraform incorporati. Questi moduli rappresentano raggruppamenti logici di risorse correlate e vengono utilizzati per condividere il codice in diversi ambienti. Il modulo modules/deploy/ qui rappresenta un modello per un deployment e viene riutilizzato per diversi deployment ambienti cloud-native.

  • Entro modules/deploy/:

    • La cartella rule/ contiene file yaml contenente regole di qualità dei dati. Un file rappresenta un insieme di regole di qualità dei dati per una tabella. Questo file viene utilizzato negli ambienti dev e prod.

    • La cartella schemas/ contiene lo schema della tabella per la tabella BigQuery di cui è stato eseguito il deployment in questa infrastruttura.

    • Il file bigquery.tf contiene la configurazione per le tabelle BigQuery create in questo deployment.

    • Il file dataplex.tf contiene un'analisi dei dati Dataplex per la qualità dei dati. Questo file viene utilizzato in combinazione con rules_file_parsing.tf per leggere le regole di qualità dei dati da un file yaml nell'ambiente.

  • Il file cloudbuild.yaml è un file di configurazione di compilazione che contiene istruzioni per Cloud Build, ad esempio come eseguire attività in base a una serie di passaggi. Questo file specifica un'esecuzione condizionale che dipende dal ramo Cloud Build sta recuperando il codice, ad esempio:

    • Per i rami dev e prod, vengono eseguiti i seguenti passaggi:

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

    • Per qualsiasi altro ramo, vengono eseguiti i seguenti passaggi:

      1. terraform init per tutte le sottocartelle environments
      2. terraform plan per tutte le environments sottocartelle

Per assicurarti che le modifiche proposte siano appropriate per ogni ambiente, terraform init e terraform plan vengono eseguiti per tutti gli ambienti. Prima del giorno unendo la richiesta di pull, puoi esaminare i piani per assicurarti che l'accesso non viene concesso a un'entità non autorizzata, ad esempio.

Configurazione di Terraform per l'archiviazione dello stato nei bucket Cloud Storage

Per impostazione predefinita, Terraform archivia stato localmente in un file denominato terraform.tfstate. Questa configurazione predefinita può complicare l'utilizzo di Terraform per i team, soprattutto quando molti utenti eseguono Terraform contemporaneamente e ogni macchina ha la propria comprensione dell' infrastruttura attuale.

Per aiutarti a evitare questi problemi, questa sezione configura un stato remoto che punta a un bucket Cloud Storage. Lo stato remoto è una funzionalità backend e, in questo tutorial, è configurato nel file 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"
  }
}

Esiste un file backend.tf separato in ciascuno degli ambienti dev e prod. È considerata una best practice l'utilizzo di un bucket Cloud Storage diverso per ogni ambiente.

Nei passaggi successivi, creerai due bucket Cloud Storage per dev e prod e modificare alcuni file in modo che puntino ai nuovi bucket progetto Google Cloud.

  1. In Cloud Shell, crea i due bucket 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. Attiva Controllo delle versioni degli oggetti per conservare la cronologia dei tuoi deployment:

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

    L'attivazione del controllo delle versioni degli oggetti aumenta i costi di archiviazione, che puoi ridurre configurando Gestione del ciclo di vita degli oggetti in modo da eliminare le versioni precedenti degli stati.

  3. Sostituisci il segnaposto PROJECT_ID con l'ID progetto nei file main.tf e backend.tf in ogni ambiente:

    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

    Su OS X o macOS, potrebbe essere necessario aggiungere due virgolette ("") dopo sed -i, come segue:

    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. Controlla se tutti i file sono stati aggiornati:

    git status

    L'output è il seguente:

    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. Esegui il commit e il push delle modifiche:

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

    A seconda della configurazione di GitHub, dovrai eseguire l'autenticazione eseguire il push delle modifiche precedenti.

Concedere le autorizzazioni all'account di servizio Cloud Build

Per consentire Account di servizio Cloud Build eseguire script Terraform con l'obiettivo di gestire le risorse Google Cloud, devi concedere l'accesso appropriato al tuo progetto. Per semplicità, editor progetto in questo tutorial. Tuttavia, se il ruolo di editor del progetto dispone di un'autorizzazione di ampio raggio, negli ambienti di produzione devi seguire le best practice per la sicurezza IT della tua azienda, in genere fornendo un accesso con privilegi minimi.

  1. In Cloud Shell, recupera l'indirizzo email dell'account di servizio Cloud Build del tuo progetto:

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

  2. Concedi l'accesso richiesto al tuo account di servizio Cloud Build:

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

Connessione diretta di Cloud Build al repository GitHub

Questa sezione mostra come installare l'app GitHub di Cloud Build. Questa installazione ti consente di collegare il tuo repository GitHub al tuo progetto Google Cloud in modo che Cloud Build possa applicare automaticamente i tuoi manifest Terraform ogni volta che crei un nuovo ramo o esegui il push del codice su GitHub.

I passaggi che seguono forniscono istruzioni per installare l'app soltanto per terraform-google-dataplex-auto-data-quality repository, ma puoi scegliere di installare l'app per più o tutti i repository.

  1. In GitHub Marketplace, vai alla pagina dell'app Cloud Build.

    • Se è la prima volta che configuri un'app in GitHub: fai clic su Configura. con Google Cloud Build in fondo alla pagina. Quindi, fai clic su Concede a questa app l'accesso al tuo account GitHub.
    • Se non è la prima volta che configuri un'app in GitHub: fai clic su Configura l'accesso. Viene visualizzata la pagina Applications (Applicazioni) del tuo account personale.

  2. Fai clic su Configura nella riga Cloud Build.

  3. Seleziona Seleziona solo i repository, quindi seleziona terraform-google-dataplex-auto-data-quality per connettersi al repository.

  4. Fai clic su Salva o Installa. L'etichetta del pulsante cambia in base al tuo flusso di lavoro. Ti reindirizzeremo a Google Cloud per continuare con dell'installazione.

  5. Accedi con il tuo account Google Cloud. Se richiesto, autorizza l'integrazione di Cloud Build con GitHub.

  6. Nella pagina Cloud Build, seleziona il tuo progetto. Viene visualizzata una procedura guidata.

  7. Nella sezione Seleziona repository, seleziona il tuo account GitHub e il terraform-google-dataplex-auto-data-quality repository.

  8. Se accetti i termini e le condizioni, seleziona la casella di controllo e poi fai clic su Connetti.

  9. Nella sezione Crea un attivatore, fai clic su Crea un attivatore:

    1. Aggiungi un nome per l'attivatore, ad esempio push-to-branch. Prendi nota del nome di questo trigger perché ne avrai bisogno in seguito.
    2. Nella sezione Evento, seleziona Push al ramo.
    3. Nella sezione Origine, seleziona .* nel campo Filiale.
    4. Fai clic su Crea.

L'app GitHub di Cloud Build è ora configurata e il tuo repository GitHub è collegato al tuo progetto Google Cloud. D'ora in poi, le modifiche il repository GitHub attiva le esecuzioni di Cloud Build, che segnalano i risultati a GitHub utilizzando Controlli GitHub.

Modificare la configurazione dell'ambiente in un nuovo ramo della funzionalità

A questo punto, hai configurato la maggior parte dell'ambiente. È quindi il momento di apportare alcune modifiche al codice nell'ambiente locale.

  1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

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

  2. Assicurati di trovarti nella filiale dev.

  3. Per aprire il file per la modifica, vai al file modules/deploy/dataplex.tf.

  4. Nella riga 19, cambia l'etichetta the_environment in environment.

  5. Aggiungi un messaggio di commit nella parte inferiore della pagina, ad esempio "modifica dell'etichetta", e seleziona Crea un nuovo ramo per questo commit e avvia una richiesta di pull.

  6. Fai clic su Proponi modifiche.

  7. Nella pagina seguente, fai clic su Crea richiesta di pull per aprire una nuova richiesta di pull con la tua modifica al ramo dev.

    Una volta aperta la richiesta di pull, viene eseguito un job Cloud Build avviato automaticamente.

  8. Fai clic su Mostra tutti i controlli e attendi che il segno di spunta diventi verde. Non unire ancora la richiesta di pull. L'unione viene eseguita in un passaggio successivo del tutorial.

  9. Fai clic su Dettagli per visualizzare ulteriori informazioni, incluso l'output del terraform plan al link Visualizza altri dettagli su Google Cloud Build.

Tieni presente che il job Cloud Build ha eseguito la pipeline definita nella cloudbuild.yaml. Come discusso in precedenza, questa pipeline ha comportamenti diversi a seconda del ramo recuperato. La build controlla se La variabile $BRANCH_NAME corrisponde a qualsiasi cartella di ambiente. In questo caso, Cloud Build esegue terraform plan per quell'ambiente. In caso contrario, Cloud Build esegue terraform plan per tutti gli ambienti per assicurarsi che la modifica proposta sia appropriata per tutti. Se uno di questi elementi questi piani non vengono eseguiti, la build non funziona.

- 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

Analogamente, il comando terraform apply viene eseguito per i branch dell'ambiente, ma viene completamente ignorato in qualsiasi altro caso. In questa sezione, hai inviato una modifiche al codice in un nuovo ramo, per cui non sono stati applicati deployment dell'infrastruttura del tuo progetto 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

Applicazione forzata dell'esecuzione di Cloud Build prima dell'unione dei rami

Per assicurarti che le unioni possano essere applicate solo quando le rispettive esecuzioni di Cloud Build sono riuscite, procedi nel seguente modo:

  1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

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

  2. Sotto il nome del repository, fai clic su Impostazioni.

  3. Nel menu a sinistra, fai clic su Filiale.

  4. In Regole di protezione dei rami, fai clic su Aggiungi regola.

  5. In Pattern del nome del ramo, digita dev.

  6. Nella sezione Proteggi i rami corrispondenti, seleziona Richiedi stato controlli da superare prima dell'unione.

  7. Cerca il nome dell'attivatore Cloud Build creato in precedenza.

  8. Fai clic su Crea.

  9. Ripeti i passaggi da 3 a 7, impostando Pattern nome ramo su prod.

Questa configurazione è importante protezione entrambi i rami dev e prod. Ciò significa che i commit devono prima essere inviati a un altro ramo e solo dopo possono essere uniti al ramo protetto. In questo tutorial, la protezione richiede che l'esecuzione di Cloud Build sia andata a buon fine per consentire l'unione.

Promozione di modifiche all'ambiente di sviluppo

Hai una richiesta di pull in attesa di essere unita. È il momento di applicare lo stato vuoi il tuo ambiente dev.

  1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

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

  2. Sotto il nome del repository, fai clic su Pull request.

  3. Fai clic sulla richiesta di pull appena creata.

  4. Fai clic su Unisci richiesta di pull, quindi su Conferma unione.

  5. Verifica che sia stato attivato un nuovo Cloud Build:

    Vai alla pagina di Cloud Build

  6. Apri la build e controlla i log. Verranno mostrate tutte le risorse che Terraform sta creando e gestendo.

Promozione di modifiche all'ambiente di produzione

Ora che il tuo ambiente di sviluppo è stato testato, puoi promuovere il codice per le regole sulla qualità dei dati in produzione.

  1. Su GitHub, vai alla pagina principale del repository creato con fork.

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

  2. Sotto il nome del repository, fai clic su Pull request.

  3. Fai clic su Nuova richiesta pull.

  4. Per il repository di base, seleziona il repository appena sottoposto a fork.

  5. Per base, seleziona prod dal tuo repository di base. Per confronta, seleziona dev.

  6. Fai clic su Crea richiesta di pull.

  7. In title, inserisci un titolo, ad esempio Changing label name, quindi fai clic su Crea pull request.

  8. Esamina le modifiche proposte, inclusi i dettagli di terraform plan di Cloud Build, quindi fai clic su Unisci richiesta pull.

  9. Fai clic su Conferma unione.

  10. Nella console Google Cloud, apri la pagina Cronologia build per vedere le modifiche applicate all'ambiente di produzione:

    Vai alla pagina Cloud Build

Hai configurato correttamente le regole sulla qualità dei dati gestite con Terraform e Cloud Build.

Esegui la pulizia

Al termine del tutorial, elimina le risorse che hai creato su Google Cloud in modo che non ti vengano addebitate in futuro.

Elimina il progetto

  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.

Eliminazione del repository GitHub

Per evitare di bloccare le nuove richieste di pull nel tuo repository GitHub, puoi eliminare le regole di protezione dei rami:

  1. In GitHub, vai alla pagina principale del repository creato con fork.
  2. Sotto il nome del repository, fai clic su Impostazioni.
  3. Nel menu a sinistra, fai clic su Filiale.
  4. Nella sezione Regole di protezione dei rami, fai clic sul pulsante Elimina. per le righe dev e prod.

Se vuoi, puoi disinstallare completamente l'app Cloud Build da GitHub:

  1. In GitHub, vai alla pagina Applicazioni GitHub.

  2. Nella scheda App GitHub installate, fai clic su Configura nella riga Cloud Build. Quindi, nella sezione Zona pericolosa, fai clic sul pulsante Disinstalla nella riga Disinstalla Google Cloud Builder.

    Nella parte superiore della pagina viene visualizzato il messaggio "Fatto. È stato messo in coda un job per la disinstallazione di Google Cloud Build."

  3. Nella scheda App GitHub autorizzate, fai clic sul pulsante Revoca nel Google Cloud Build, quindi Ho capito, revoca l'accesso.

Se non vuoi conservare il tuo repository GitHub:

  1. In GitHub, vai alla pagina principale del repository di cui hai creato un fork.
  2. Sotto il nome del repository, fai clic su Impostazioni.
  3. Vai a Danger Zone.
  4. Fai clic su Elimina questo repository e segui i passaggi per la conferma.

Passaggi successivi