Notez que vous consultez la documentation Looker. Pour accéder à la documentation sur Looker Studio, consultez la page https://support.google.com/looker-studio.

Cette page a été traduite par l'API Cloud Translation.

Utilisation et workflow du CI/CD Looker

Cette page explique comment utiliser un workflow CI/CD dans Looker après qu'il a été installé et configuré.

Ces instructions reposent sur un système à trois niveaux comprenant le développement, le contrôle qualité et la production. Toutefois, vous pouvez appliquer les mêmes principes à un système à deux ou quatre niveaux.

Ces instructions supposent également que vous utilisez GitHub comme fournisseur Git. Vous pouvez faire appel à d'autres fournisseurs Git pour créer un workflow CI/CD. Cependant, vous devez posséder les compétences nécessaires pour modifier ces instructions pour votre fournisseur.

Présentation du workflow

Les développeurs LookML commencent par écrire le code dans leur branche de développement, normalement nommée dev-my-user-ydnv, par exemple, puis les testent avec Spectacles et valident leur code. Enfin, il ouvre une demande d'extraction pour fusionner son code avec la branche main.

Lorsque la demande d'extraction est ouverte, le développeur est redirigé vers GitHub. Le développeur doit rédiger un titre de relations publiques pertinent en utilisant un style de validations conventionnel et ajouter un commentaire à la description qui sera inclus dans le journal des modifications. Les résultats des tests Spectacles doivent être ajoutés sous forme de commentaires au communiqué.

Ensuite, le développeur doit sélectionner un examinateur dans GitHub. L'examinateur reçoit une notification et peut ajouter son avis au rapport d'équipe. Si le réviseur approuve la modification, le PR est fusionné avec la branche main. Un webhook est appelé et l'environnement de développement voit maintenant la modification.

L'automatisation Release Please s'exécute automatiquement et ouvre une deuxième demande de publication pour créer une version taguée. S'il existe déjà un communiqué de presse en cours à cette fin, veuillez le mettre à jour. Le PR de la version est associé à un numéro de version, ainsi qu'à un journal de modifications qui comprend les titres et les descriptions des modifications incluses.

Lorsque le PR généré est approuvé et fusionné, un nouveau tag de version est généré et le journal des modifications est fusionné avec la branche main. Les instances de contrôle qualité et de production de Looker peuvent sélectionner cette version à l'aide du mode de déploiement avancé.

Bonnes pratiques concernant la numérotation des versions et l'attribution de noms aux commits

Vous pouvez nommer et numéroter les versions et les balises associées de n'importe quelle manière qui vous semble appropriée dans votre environnement. Toutefois, la gestion sémantique des versions est utilisée ici. Elle est vivement recommandée, car elle fonctionne bien avec le plug-in Publier SVP.

Dans la gestion sémantique des versions, la version se compose de trois nombres séparés par des points : MAJOR.MINOR.PATCH

PATCH est incrémenté chaque fois qu'une version corrige un bug.
MINOR est incrémenté et PATCH est réinitialisé à zéro chaque fois que la version ajoute ou affine une fonctionnalité tout en étant rétrocompatible.
MAJOR est incrémenté, et MINOR et PATCH sont définis sur zéro lorsqu'une fonctionnalité non rétrocompatible est ajoutée.

Les commits conventionnels sont un système de dénomination des commits en fonction de leur impact sur les utilisateurs finaux. Bien que cela ne soit pas obligatoire, l'utilisation d'un nom de commit conventionnel est également utile pour le plug-in Release Please.

Dans la dénomination conventionnelle des commits, chaque message de commit est précédé d'un indicateur de la portée du changement :

Une correction de bug est indiquée par fix:, comme fix: set proper currency symbol on sale_amt format.
Une nouvelle fonctionnalité est indiquée par feat:, par exemple feat: added explore for sales by territory
Une fonctionnalité avec une modification destructive est indiquée par feat!:, par exemple feat!: rewrote sales explore to use the new calendar view
Lorsque les documents sont mis à jour, mais que le code LookML n'est pas modifié, le message de commit commence par doc:.

Si les commits conventionnels sont utilisés de manière cohérente, il est généralement simple de déterminer le nombre sémantique à utiliser ensuite. Si le journal des commits ne contient que des commits fix: et doc:, PATCH doit être incrémenté. Si un commit feat: est effectué, MINOR doit être incrémenté. Si un feat!: est présent, MAJOR doit être incrémenté. Le plug-in Release Please peut même générer un fichier CHANGELOG et ajouter automatiquement un tag à la version.

Utiliser le mode Déploiement avancé

Une fois les modifications effectuées et envoyées en tant que PR sur l'instance de développement, le plug-in Release Please ajoute une balise de version telle que v1.2.3 aux modifications. Le mode de déploiement avancé de Looker rend ensuite ces versions disponibles dans l'interface utilisateur de Looker pour les instances de contrôle qualité et de production.

Pour déployer une modification, choisissez Deployment Manager dans l'IDE Looker:

Emplacement de Looker Deployment Manager dans l'IDE.

Cliquez sur le lien Select Commit (Sélectionner le commit) en haut à droite du Gestionnaire de déploiement. Ensuite, sélectionnez le menu à trois points associé au tag que vous souhaitez déployer, puis choisissez Déployer dans l'environnement:

Interface utilisateur de Looker Deployment Manager pour le déploiement dans un environnement.

Vous n'avez pas besoin de taguer à nouveau le déploiement. Choisissez donc Déployer sans taguer, puis appuyez sur le bouton Déployer dans l'environnement :

Interface utilisateur de Looker Deployment Manager pour le déploiement sans ajout de tags

Enfin, déployez l'application en production à l'aide de Deployment Manager.

Utilisation de lunettes

Chaque développeur peut utiliser Spectacles pour vérifier ses modifications lorsqu'elles se trouvent encore dans sa branche de développement. Spectacles propose quatre outils de validation différents:

SQL
LookML
Contenu
Assert

Lorsqu'un développeur envoie une demande d'extraction, il est recommandé d'exécuter ces tests et de copier les résultats dans un commentaire sur le PR.

Outil de validation SQL

L'outil de validation SQL teste chaque exploration pour s'assurer que tous les champs définis dans les vues LookML correspondent à des colonnes SQL réelles ou à des expressions SQL valides dans la base de données. L'outil de validation SQL est appelé comme indiqué ci-dessous:

$ spectacles sql --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Exemple :

$ spectacles sql --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

=================== Testing 1/1 explores [concurrency = 10] ===================

✓ thelook_cicd.users passed

Completed SQL validation in 1 minute and 7 seconds.

Programme de validation de LookML

Le programme de validation LookML garantit que les modifications LookML sont valides et ne comportent aucune erreur de syntaxe. Il est appelé comme indiqué ci-dessous :

$ spectacles lookml --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --branch DEV_BRANCH_NAME

Exemple :

$ spectacles lookml --config-file config-dev.yaml \
    --project thelook_cicd \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

============= Validating LookML in project thelook_cicd [warning] ==============

✗ thelook_cicd/business_pulse.dashboard.lookml failed
✗ thelook_cicd/thelook_cicd.model.lkml failed

================ thelook_cicd/business_pulse.dashboard.lookml:28 ===============

[Error] Unknown field "users.state" in explore "users" for field_filter.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=28

================ thelook_cicd/business_pulse.dashboard.lookml:36 ===============

[Warning] Unknown field "users.state" (for explore "orders" in model
"thelook_cicd") referenced in dashboard element.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=36

[Additional errors snipped]

Completed validation in 6 seconds.

Validation de contenu

L'outil de validation du contenu vérifie que tout contenu enregistré, comme les looks et les tableaux de bord définis par l'utilisateur, continue de fonctionner après les modifications. Afin d'accélérer l'exécution du job et de fournir des résultats gérables, la validation n'est effectuée que pour le contenu basé sur les explorations que vous spécifiez. Le vérificateur de contenu est appelé comme suit :

$ spectacles content --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Exemple :

$ spectacles content --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Validating content based on 5 explores ====================

✗ thelook_cicd.users failed

================= test dashboard for spectacles [TheLook_CICD] =================

Tile 'test dashboard for spectacles' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/223

========================= Business Pulse [TheLook_CICD] ========================

Filter 'State / Region' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/190

Completed content validation in 27 seconds.

Validation d'assertion

La fonctionnalité "Assert Validation" teste les assertions de données que vous avez ajoutées à votre code LookML pour vous assurer que les données sont lues correctement. Par exemple, un test de données dans votre code LookML peut se présenter comme suit:

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

La validation d'assertion est appelée comme indiqué ci-dessous :

$ spectacles assert --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Exemple :

$ spectacles assert --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Running data tests based on 1 explore =====================

✗ thelook_cicd.users failed

================ thelook_cicd/users/california_users_is_accurate ===============

Unknown filter field "users.state" in lookml test "california_users_is_accurate"
declaration.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Invalid filter: users.state

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Assertion "count_is_expected_value" failed: expression evaluated to "No".

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

Completed data test validation in 14 seconds.

Stabilité des liens pour les looks et les tableaux de bord

Par défaut, les présentations et les tableaux de bord sont associés à des ID numériques croissants qui sont utilisés dans l'URL de la présentation ou du tableau de bord. Cependant, il n'existe aucun moyen de les garder synchronisées sur plusieurs systèmes. Par conséquent, l'URL d'un tableau de bord spécifique en cours de développement ne renverra pas vers le même tableau de bord en phase de contrôle qualité ou de production.

Pour les UDD, il est possible d'utiliser un slug au lieu d'un ID dans l'URL. Le slug est un ensemble semi-aléatoire de caractères plutôt qu'un nombre. Le slug peut être défini lors de l'importation afin qu'une URL similaire puisse pointer vers le même UDD en développement, en contrôle qualité et en production. Il est recommandé d'utiliser des slugs au lieu d'ID, en particulier lorsque vous cliquez sur une UDD à partir d'une recherche ou d'une autre UDD.

Vous pouvez trouver le slug en inspectant la sortie de gzr dashboard cat. Vous pouvez utiliser le slug dans l'URL du tableau de bord à la place de l'ID numérique.

Migrer le contenu des utilisateurs avec Gazer

Il est souvent utile de copier des contenus tels que des looks et des tableaux de bord entre les environnements de développement, de test et de production. Vous pouvez créer du contenu qui présente les nouveaux ajouts LookML ou vous assurer que le contenu enregistré fonctionne toujours correctement après les modifications apportées à LookML. Dans ces situations, Gazer peut être utilisé pour copier du contenu entre les instances.

Tableaux de bord LookML

Les tableaux de bord LookML sont synchronisés entre les instances au cours du workflow CI/CD LookML standard. Toutefois, si des UDD sont synchronisés avec des tableaux de bord LookML, vous pouvez les mettre à jour avec Gazer à l'aide de la commande suivante:

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

Tableaux de bord définis par l'utilisateur

Les tableaux de bord définis par l'utilisateur peuvent être migrés avec Gazer en référençant l'ID du tableau de bord et l'URL de l'instance Looker dans laquelle il se trouve. Gazer enregistre la configuration du tableau de bord dans un fichier JSON, qui est ensuite importé dans l'instance Looker cible.

La commande permettant d'extraire la configuration UDD est la suivante:

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

Un fichier nommé Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json contenant la configuration du tableau de bord est alors généré.

Vous pouvez importer l'UDD dans le système cible à l'aide de la commande suivante:

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

Looks

La migration de Look fonctionne de manière très semblable à la migration de l'UDD. Commencez par utiliser Gazer pour enregistrer la configuration du look dans un fichier JSON :

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

Ensuite, importez la présentation dans l'instance cible:

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