Utilisation et workflow CI/CD Looker multicouches

Cette page explique comment utiliser un workflow CI/CD multicouche dans Looker après l'avoir installé et configuré.

Ces instructions utilisent 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 utiliser d'autres fournisseurs Git pour créer un workflow CI/CD. Toutefois, vous devez avoir l'expertise nécessaire pour modifier ces instructions pour votre fournisseur.

Présentation du workflow

Les développeurs LookML commencent par écrire du code dans leur branche de développement, qui est généralement nommée dev-my-user-ydnv, testent leurs modifications avec l'intégration continue Looker (ou en exécutant manuellement une suite CI), puis 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 demande d'extraction pertinent en utilisant le style des commits conventionnels et ajouter un commentaire à la description qui sera inclus dans le journal des modifications. Si le déclenchement des demandes d'extraction est configuré, l'intégration continue de Looker valide automatiquement la demande d'extraction;extraction. Les développeurs peuvent afficher les résultats dans Looker ou GitHub.

Ensuite, le développeur doit sélectionner un réviseur dans GitHub. Le réviseur recevra une notification et pourra ajouter son avis à la demande de pull. Si le réviseur approuve la modification, la demande de pull est fusionnée avec la branche main. Un WebHook est appelé et l'environnement de développement voit maintenant le changement.

L'automatisation Release Please s'exécute automatiquement et ouvre une deuxième demande d'extraction pour créer une version taguée. Si une demande d'extraction est déjà ouverte à cet effet, Release Please la met à jour. Le RP de version est associé à un numéro de version, ainsi qu'à un journal des modifications qui inclut les titres et les descriptions des modifications incluses.

Lorsque la demande d'extraction générée par Release Please est approuvée et fusionnée, un tag de version est généré et le journal des modifications est fusionné avec la branche main. Les instances Looker de production et d'assurance qualité peuvent sélectionner cette version à l'aide du mode de déploiement avancé.

Bonnes pratiques pour numéroter les versions et nommer les commits

Les versions et leurs tags associés peuvent être nommés et numérotés de la manière la plus adaptée à votre environnement. Toutefois, la gestion sémantique des versions est utilisée ici et est fortement recommandée, car elle fonctionne bien avec le plug-in Release Please.

Dans le versionnage sémantique, 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 remis à 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.

Conventional Commits est 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 de noms de commit conventionnels est également utile pour le plug-in Release Please.

Dans la convention de nommage des commits, chaque message de commit est précédé d'un indicateur de l'étendue de la modification :

  • 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:, comme feat: added explore for sales by territory.
  • Une fonctionnalité avec un changement incompatible est indiquée par feat!:, comme feat!: rewrote sales explore to use the new calendar view.
  • Lorsque la documentation est mise à 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 facile de déterminer le numéro sémantique à utiliser ensuite. Si le journal des commits ne contient que des commits fix: et doc:, le PATCH doit être incrémenté. Si un commit feat: est présent, 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 taguer la version automatiquement.

Utiliser le mode Déploiement avancé

Une fois les modifications apportées et envoyées en tant que demande d'extraction sur l'instance de développement, le plug-in Release Please les taguera avec un tag de version tel que v1.2.3. Le mode de déploiement avancé de Looker rend ensuite ces versions disponibles dans l'interface utilisateur de Looker pour les instances de QA et de production.

Pour déployer une modification, sélectionnez le gestionnaire de déploiement dans l'IDE Looker :

Emplacement du gestionnaire de déploiement Looker dans l'IDE.

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

Interface utilisateur Looker Deployment Manager pour le déploiement dans l'environnement.

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

Interface utilisateur de Deployment Manager Looker pour le déploiement sans tag.

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

Utiliser l'intégration continue Looker

Pour vérifier les modifications dans une branche de développement ou dans une demande d'extraction;extraction, les développeurs peuvent utiliser l'intégration continue de Looker. L'intégration continue fournit quatre validateurs :

Vous pouvez regrouper ces validateurs dans des suites d'intégration continue et les exécuter automatiquement sur les requêtes d'extraction, selon une programmation ou manuellement.

Programme de validation SQL

Le validateur SQL d'intégration continue vérifie que les dimensions de vos explorations s'exécutent correctement par rapport à votre base de données. Il vérifie si les champs définis dans les vues LookML correspondent à des colonnes ou expressions SQL valides dans la base de données.

Le validateur SQL offre les principales fonctionnalités suivantes :

Pour en savoir plus et découvrir les options de configuration, consultez la page de documentation Validateur SQL d'intégration continue.

Programme de validation LookML

Le validateur LookML d'intégration continue vérifie que votre projet LookML ne contient pas d'erreurs de syntaxe, comme des crochets manquants ou des références de champ non valides. Ce validateur est particulièrement utile pour les développeurs qui écrivent du code LookML en dehors de l'IDE Looker.

Le validateur LookML offre les principales fonctionnalités suivantes :

  • Vous permet de définir un seuil de gravité (Erreur, Avertissement ou Info) qui détermine le niveau de gravité des messages entraînant l'échec d'une exécution.
  • Vous permet de configurer une durée de délai avant expiration pour les exécutions de validation.

Pour en savoir plus et découvrir les options de configuration, consultez la page de documentation Validateur LookML pour l'intégration continue.

Validation de contenu

Le validateur de contenu d'intégration continue vérifie que le contenu enregistré, tel que les Looks et les tableaux de bord définis par l'utilisateur (UDD), fonctionne toujours correctement après avoir apporté des modifications à LookML.

Le validateur de contenu offre les principales fonctionnalités suivantes :

Pour en savoir plus et découvrir les options de configuration, consultez la page de documentation Continuous Integration Content Validator.

Programme de validation Assert

Le validateur d'assertions d'intégration continue exécute les tests de données LookML définis dans votre projet pour vérifier la logique du modèle et l'intégrité des données.

Par exemple, un test de données 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: "2024"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

Le validateur d'assertions présente les principales fonctionnalités suivantes :

Pour en savoir plus et découvrir les options de configuration, consultez la page de documentation Continuous Integration Assert Validator.

Gérer et exécuter des suites CI

Pour gérer et exécuter des tests d'intégration continue, procédez comme suit :

Par défaut, les Looks et les tableaux de bord reçoivent des ID numériques croissants qui sont utilisés dans l'URL du Look ou du tableau de bord. Toutefois, il n'existe aucun moyen de les synchroniser entre les systèmes. Par conséquent, l'URL d'un tableau de bord spécifique en cours de développement ne pointera pas vers le même tableau de bord en contrôle qualité ou en production.

Pour les UDD, vous pouvez utiliser un slug au lieu d'un ID dans l'URL. Le slug est un ensemble de caractères semi-aléatoires 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 dans les environnements de développement, de contrôle qualité et de production. Il est recommandé d'utiliser des slugs plutôt que des ID, en particulier lorsque vous cliquez sur une UDD à partir de Look ou d'une autre UDD.

Vous trouverez le slug en inspectant la sortie de gzr dashboard cat. Le slug peut être utilisé dans l'URL du tableau de bord à la place de l'ID numérique.

Migrer le contenu utilisateur avec Gazer

Il est souvent utile de copier du contenu tel que des Looks et des tableaux de bord entre les environnements de développement, d'assurance qualité et de production. Vous pouvez créer du contenu qui présente les nouveaux ajouts LookML ou vérifier que le contenu enregistré fonctionne toujours correctement après les modifications 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 lors du workflow CI/CD LookML habituel. Toutefois, si des tableaux de bord définis par l'utilisateur sont synchronisés avec des tableaux de bord LookML, ils peuvent être mis à 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 où réside le tableau de bord défini par l'utilisateur. 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é.

Le fichier UDD peut être importé 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 des looks fonctionne de manière très similaire à la migration des données définies par l'utilisateur. Commencez par utiliser Gazer pour enregistrer la configuration du Look dans un fichier JSON :

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

Importez ensuite le Look dans l'instance cible :

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