Utilizzo e flusso di lavoro CI/CD di Looker a più livelli

Questa pagina spiega come utilizzare un flusso di lavoro CI/CD multilivello in Looker dopo che è stato installato e configurato.

Queste istruzioni utilizzano un sistema a tre livelli che comprende sviluppo, QA e produzione. Tuttavia, puoi applicare gli stessi principi a un sistema a due o quattro livelli.

Queste istruzioni presuppongono anche l'utilizzo di GitHub come provider Git. Puoi utilizzare altri provider Git per creare un flusso di lavoro CI/CD; tuttavia, devi avere le competenze per modificare queste istruzioni per il tuo provider.

Panoramica del flusso di lavoro

Gli sviluppatori LookML iniziano scrivendo il codice nel ramo di sviluppo, che in genere ha un nome come dev-my-user-ydnv, testano le modifiche con Looker Continuous Integration (o eseguendo manualmente una suite CI) ed eseguono il commit del codice. Infine, aprono una richiesta di pull per unire il codice al ramo main.

Quando la richiesta di pull viene aperta, lo sviluppatore viene indirizzato a GitHub. Lo sviluppatore deve scrivere un titolo significativo per la richiesta di pull utilizzando lo stile dei commit convenzionali e aggiungere un commento alla descrizione che verrà incluso nel log delle modifiche. Se è configurata l'attivazione della richiesta di pull, Looker Continuous Integration convalida automaticamente la richiesta di pull e gli sviluppatori possono visualizzare i risultati in Looker o in GitHub.

Successivamente, lo sviluppatore deve selezionare un revisore in GitHub. Il revisore riceverà una notifica e potrà aggiungere la sua revisione alla richiesta di pull. Se il revisore approva la modifica, la richiesta di pull viene unita al ramo main. Viene chiamato un webhook e l'ambiente di sviluppo ora vede la modifica.

Automaticamente, verrà eseguita l'automazione Release Please e verrà aperta una seconda richiesta pull per creare una nuova release taggata. In alternativa, se è già aperta una richiesta pull per questo scopo, Release Please la aggiorna. La richiesta pull di rilascio ha un numero di versione associato, nonché un changelog che include i titoli e le descrizioni delle modifiche incluse.

Quando la richiesta di pull generata da Release Please viene approvata e unita, viene generato un nuovo tag di versione e il log delle modifiche viene unito al ramo main. Le istanze QA e di produzione di Looker possono selezionare questa versione utilizzando la modalità di deployment avanzata.

Best practice per la numerazione delle release e la denominazione dei commit

Le release e i relativi tag possono essere denominati e numerati in qualsiasi modo abbia senso nel tuo ambiente. Tuttavia, qui viene utilizzato il controllo delle versioni semantico, che è vivamente consigliato perché funziona bene con il plug-in Release Please.

Nel controllo delle versioni semantico, la versione è composta da tre numeri separati da punti: MAJOR.MINOR.PATCH

  • PATCH viene incrementato ogni volta che una release corregge un bug
  • MINOR viene incrementato e PATCH viene riportato a zero ogni volta che la release aggiunge o perfeziona una funzionalità mantenendo la compatibilità con le versioni precedenti
  • MAJOR viene incrementato e sia MINOR che PATCH vengono impostati su zero quando viene aggiunta una funzionalità non compatibile con le versioni precedenti

Conventional Commits è un sistema di denominazione dei commit in base all'impatto che hanno sugli utenti finali. Sebbene non sia obbligatorio, l'utilizzo di nomi di commit convenzionali è utile anche per il plug-in Release Please.

Nella denominazione convenzionale dei commit, ogni messaggio di commit è preceduto da un indicatore dell'ambito della modifica:

  • La correzione di un bug è indicata con fix:, ad esempio fix: set proper currency symbol on sale_amt format
  • Una nuova funzionalità è indicata con feat:, ad esempio feat: added explore for sales by territory
  • Una funzionalità con una modifica che causa interruzioni è indicata da feat!:, ad esempio feat!: rewrote sales explore to use the new calendar view
  • Quando la documentazione viene aggiornata, ma LookML non viene modificato, il messaggio di commit inizia con doc:

Se i commit convenzionali vengono utilizzati in modo coerente, determinare il numero semantico da utilizzare successivamente è generalmente semplice. Se il log dei commit è composto solo da commit fix: e doc:, PATCH deve essere incrementato. Se è presente un commit feat:, MINOR deve essere incrementato. Se è presente un feat!:, MAJOR deve essere incrementato. Il plug-in Release Please può persino generare un file CHANGELOG e taggare automaticamente la release.

Utilizzo della modalità di deployment avanzata

Dopo che le modifiche sono state apportate e inviate come richiesta di pull nell'istanza di sviluppo, il plug-in Release Please contrassegnerà le modifiche con un tag di versione come v1.2.3. La modalità di deployment avanzata di Looker rende quindi disponibili queste versioni nell'interfaccia utente di Looker per le istanze QA e di produzione.

Per eseguire il deployment di una modifica, scegli Deployment Manager dall'IDE di Looker:

Posizione di Deployment Manager di Looker nell'IDE.

Fai clic sul link Seleziona commit in alto a destra di Deployment Manager. Poi, seleziona il menu con tre puntini associato al tag di cui vuoi eseguire il deployment e scegli Esegui il deployment nell'ambiente:

Interfaccia utente di Looker Deployment Manager per il deployment nell'ambiente.

Non è necessario taggare di nuovo il deployment, quindi scegli Esegui il deployment senza tagging e premi il pulsante Esegui il deployment nell'ambiente:

Interfaccia utente di Looker Deployment Manager per il deployment senza tagging.

Infine, esegui il push in produzione utilizzando Deployment Manager.

Utilizzo di Looker Continuous Integration

Per verificare le modifiche in un ramo di sviluppo o nell'ambito di una richiesta di pull, gli sviluppatori possono utilizzare Looker Continuous Integration. L'integrazione continua fornisce i seguenti validatori:

Puoi raggruppare questi validatori in suite di integrazione continua ed eseguirli automaticamente sulle richieste di pull, in base a una pianificazione o manualmente.

Strumento di convalida SQL

Lo strumento di convalida SQL per l'integrazione continua verifica che le dimensioni nelle esplorazioni vengano eseguite correttamente nel database. Verifica se i campi definiti nelle visualizzazioni LookML corrispondono a colonne o espressioni SQL valide nel database.

SQL Validator offre le seguenti funzionalità principali:

Per ulteriori informazioni e opzioni di configurazione, consulta la pagina di documentazione Continuous Integration SQL Validator.

Strumento di convalida LookML

Lo strumento di convalida LookML per l'integrazione continua controlla la presenza di errori di sintassi nel progetto LookML, ad esempio parentesi mancanti o riferimenti di campo non validi. Questo strumento di convalida è particolarmente utile per gli sviluppatori che scrivono codice LookML al di fuori dell'IDE di Looker.

LookML Validator offre le seguenti funzionalità principali:

  • Consente di impostare una soglia di gravità (Errore, Avviso o Informazioni) che determina il livello di gravità del messaggio che causa l'esito negativo di un'esecuzione.
  • Consente di configurare una durata di timeout per le esecuzioni di convalida.

Per ulteriori informazioni e opzioni di configurazione, consulta la pagina della documentazione Continuous Integration LookML Validator.

strumento di convalida dei contenuti

Lo strumento di convalida dei contenuti di integrazione continua verifica che i contenuti salvati, come i Look e le dashboard definite dall'utente, continuino a funzionare correttamente dopo le modifiche a LookML.

Lo strumento di convalida dei contenuti offre le seguenti funzionalità principali:

Per ulteriori informazioni e opzioni di configurazione, consulta la pagina della documentazione Continuous Integration Content Validator.

Strumento di convalida Assert

Lo strumento di convalida delle asserzioni di integrazione continua esegue i test sui dati LookML definiti nel progetto per verificare la logica del modello e l'integrità dei dati.

Ad esempio, un test dei dati LookML potrebbe avere il seguente aspetto:

test: historic_revenue_is_accurate {
  explore_source: orders {
    column: total_revenue { field: orders.total_revenue }
    filters: [orders.created_date: "2024"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

Lo strumento di convalida delle asserzioni offre le seguenti funzionalità principali:

Per ulteriori informazioni e opzioni di configurazione, consulta la pagina di documentazione Continuous Integration Assert Validator.

Gestione ed esecuzione di suite CI

Per gestire ed eseguire i test di integrazione continua:

Per impostazione predefinita, a Look e dashboard vengono assegnati ID numerici crescenti utilizzati nell'URL del Look o della dashboard. Tuttavia, non è possibile mantenerli sincronizzati tra i sistemi. Pertanto, un URL per una specifica dashboard in fase di sviluppo non rimanderà alla stessa dashboard in QA o produzione.

Per gli UDD è disponibile un'opzione per utilizzare uno slug anziché un ID come parte dell'URL. Lo slug è un insieme di caratteri semi-casuali anziché un numero. Lo slug può essere impostato durante l'importazione, in modo che un URL simile possa indirizzare alla stessa UDD in sviluppo, QA e produzione. L'utilizzo di slug anziché ID è una best practice, in particolare quando si fa clic su una UDD da un Look o da un'altra UDD.

Lo slug può essere trovato esaminando l'output di gzr dashboard cat. Lo slug può essere utilizzato nell'URL della dashboard al posto dell'ID numerico.

Migrazione dei contenuti degli utenti con Gazer

Copiare contenuti come Look e dashboard tra sviluppo, controllo qualità e produzione è spesso utile. Potresti voler produrre contenuti che mostrino le nuove aggiunte di LookML o verificare che i contenuti salvati funzionino ancora correttamente dopo le modifiche a LookML. In queste situazioni, Gazer può essere utilizzato per copiare i contenuti tra le istanze.

Dashboard LookML

Le dashboard LookML vengono sincronizzate tra le istanze durante il normale flusso di lavoro CI/CD di LookML. Tuttavia, se uno qualsiasi dei dataset definiti dall'utente viene sincronizzato con le dashboard LookML, può essere aggiornato con Gazer utilizzando il seguente comando:

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

Dashboard definite dall'utente

Le dashboard definite dall'utente (UDD) possono essere migrate con Gazer facendo riferimento all'ID della dashboard e all'URL dell'istanza di Looker in cui si trova la UDD. Gazer salva la configurazione del dashboard in un file JSON, che viene poi importato nell'istanza Looker di destinazione.

Il comando per estrarre la configurazione UDD è il seguente:

gzr dashboard cat DASHBOARD_ID --host TARGET_SYSTEM_URL --dir .

Verrà generato un file denominato Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json contenente la configurazione del dashboard.

Il pacchetto UDD può essere importato nel sistema di destinazione utilizzando il seguente comando:

gzr dashboard import Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL

Look

La migrazione dei Look funziona in modo molto simile alla migrazione delle dashboard definite dall'utente. Innanzitutto, utilizza Gazer per salvare la configurazione della visualizzazione in un file JSON:

gzr look cat LOOK_ID --host SOURCE_SYSTEM_URL --dir .

Quindi, importa il Look nell'istanza target:

gzr look import Look_LOOK_ID_LOOK_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL