Utiliser le contrôle des versions et le déploiement

Dans cette page, nous partons du principe que votre projet a déjà été configuré pour le contrôle des versions. Si un bouton Configurer Git s'affiche à la place des options décrites sur cette page, vous devez d'abord configurer Git pour votre projet.

Intégration de Git pour le contrôle des versions

Looker utilise Git pour enregistrer les modifications et gérer les versions de fichiers. Chaque projet LookML correspond à un dépôt Git, et chaque branche de développeur est liée à une branche Git. Les dépôts Git sont souvent appelés dépôts.

Looker utilise généralement GitHub pour la gestion des fichiers sources LookML. Toutefois, Looker peut être configuré pour fonctionner avec d'autres fournisseurs Git tels que GitLab, Bitbucket ou tout serveur Git pouvant utiliser une clé SSH pour l'authentification.

GitHub n'accepte pas les mots de passe de compte pour authentifier les opérations Git sur github.com. Pour en savoir plus, consultez l'article de blog GitHub. Pour connecter un projet Looker à GitHub à l'aide du protocole HTTPS, utilisez les paramètres du développeur dans GitHub pour créer un jeton d'accès personnel. Pour les projets Looker existants qui se connectent à GitHub à l'aide du protocole HTTPS, réinitialisez votre connexion Git à l'aide d'un jeton d'accès personnel depuis GitHub.

Un projet Looker n'utilise qu'un seul compte avec votre fournisseur Git pour toutes les interactions Git (consultez la page de documentation Intégrer Looker avec Git pour en savoir plus sur la configuration de Git). Pour chaque projet Looker, le développement de tous vos développeurs Looker passe par un seul compte Git. Les développeurs Looker n'ont donc pas besoin de posséder leur propre compte auprès de votre fournisseur Git, sauf si votre instance Looker est configurée avec l'une des options d'intégration Git supplémentaires. Dans ce cas, un développeur Looker a besoin d'un compte Git pour ouvrir des liens externes vers votre fournisseur Git ou créer une demande d'extraction.

Utiliser des branches Git

L'un des principaux avantages de Git est qu'un développeur Looker peut travailler dans une branche, une version isolée d'un dépôt de fichiers. Vous pouvez développer et tester votre application sans affecter les autres utilisateurs. En tant que développeur dans Looker, vous utilisez une branche Git chaque fois que vous êtes en mode de développement.

La facilité de collaboration avec d'autres développeurs est un autre atout majeur de Git. Vous pouvez créer une branche et y apporter des modifications si vous le souhaitez. Les autres développeurs pourront alors passer à cette branche pour examiner ou modifier la branche. Si un autre développeur a validé les modifications de la branche, Looker affiche le bouton Extraire les modifications à distance. Vous devez extraire ces modifications validées de la branche avant d'apporter des modifications supplémentaires.

Vous pouvez également supprimer une branche principale autre que la branche principale, la branche actuelle ou la branche personnelle du développeur.

Branches personnelles

La première fois que vous accédez au mode de développement, Looker crée automatiquement votre branche Git personnelle. Votre branche personnelle commence par dev- et comprend votre nom:

Votre branche personnelle vous est propre. Vous ne pouvez pas la supprimer. Tous les autres développeurs ont accès à votre branche personnelle. Si vous collaborez avec d'autres développeurs sur un projet, vous pouvez créer une branche afin que les autres utilisateurs puissent basculer sur cette branche et apporter des modifications.

CONSEIL: Vous ne pouvez pas modifier une branche personnelle d'un autre développeur. Pour poursuivre le travail dans la branche personnelle d'un tiers, créez une nouvelle branche à partir de sa branche.

Créer une branche Git

Si vous travaillez sur une solution simple et que vous ne collaborez pas avec d'autres développeurs, votre branche personnelle est généralement un bon endroit pour travailler. Vous pouvez utiliser votre branche personnelle pour effectuer des mises à jour rapides, puis valider les modifications et les envoyer en production.

Toutefois, vous pouvez également créer des branches Git en plus de votre branche personnelle. Une nouvelle branche Git est logique dans les cas suivants:

  • Vous collaborez avec d'autres développeurs. Étant donné que votre branche personnelle est en lecture seule pour les autres développeurs, vous devez créer une branche Git pour pouvoir collaborer avec d'autres. Lorsque vous collaborez avec d'autres personnes, veillez à extraire les modifications à chaque fois que vous reprenez le travail. De cette façon, vous serez informé des dernières mises à jour de tous les développeurs avant de continuer à travailler.
  • Vous travaillez sur plusieurs ensembles de fonctionnalités à la fois. Il peut arriver que vous soyez en pleine phase d'un projet majeur, mais que vous souhaitiez résoudre un problème mineur ou y remédier rapidement. Dans ce cas, vous pouvez appliquer vos modifications à la branche active, puis créer ou basculer vers une autre branche pour travailler sur un ensemble distinct de fonctionnalités. Vous pouvez apporter votre correction dans la nouvelle branche, puis déployer les modifications de cette branche en production avant de reprendre le travail dans votre branche d'origine.

Avant de créer une branche:

  • Si vous rencontrez un conflit de fusion dans votre branche actuelle, vous devez résoudre le conflit avant de pouvoir créer une nouvelle branche.
  • Si vous avez des modifications non validées sur la branche actuelle, vous devez valider les modifications sur votre branche actuelle avant de créer une nouvelle branche.
  • Si vous souhaitez créer une branche à partir d'une branche de développement existante (et non de la branche de production), commencez par obtenir la dernière version de la branche de développement en basculant vers cette branche, puis extraire les modifications à distance pour synchroniser votre version locale de cette branche.

Pour créer une branche Git:

  1. Vérifiez que le mode Développement est activé.

  2. Accédez aux fichiers de votre projet dans le menu Develop (Développer).

  3. Cliquez sur l'icône Git dans le menu de gauche pour ouvrir le panneau Actions Git.

  4. Cliquez sur le menu déroulant View Branches (Afficher les branches).

  5. Sélectionnez New Branch (Nouvelle branche).

  6. Dans la fenêtre Nouvelle branche, saisissez le nom de votre branche. Notez que les noms des branches Git présentent des limites. Pour connaître les exigences concernant l'attribution de noms, consultez la section Règles pour nommer une branche Git sur cette page.

  7. Cliquez sur le menu déroulant Create From (Créer à partir de), puis sélectionnez une branche existante à utiliser comme point de départ de votre nouvelle branche.

  8. Cliquez sur Créer pour créer votre branche.

Vous pouvez également créer des branches Git à partir de l'onglet Branch Management (Gestion des branches) de la page Project Settings (Paramètres du projet).

Règles de dénomination d'une branche Git

Looker utilise les exigences concernant les conventions de nom de branche spécifiées par Git.

Les noms des branches Git ne doivent pas :

  • Contenir un caractère d'espacement
  • Contenir deux périodes de règles : ..
  • Contient une barre oblique inverse: \
  • Contient la séquence: @{
  • Contenir un point d'interrogation : ?
  • Contient un crochet ouvrant : [
  • Contenir un caractère de contrôle ASCII: ~, \^ ou :
  • Commencez par un point: .
  • Commencez par le préfixe dev- (réservé aux branches personnelles des développeurs Looker).
  • Se terminer par une barre oblique : /
  • Se terminer par l'extension .lock

En outre, le nom de la branche ne peut contenir d'astérisque (*) que s'il représente un composant de chemin complet (par exemple, foo/* ou bar/*/baz). Dans ce cas, il est interprété comme un caractère générique et non comme faisant partie du nom de la branche.

Passer à une autre branche Git

Si vous rencontrez un conflit de fusion dans votre branche actuelle, vous devez résoudre le conflit avant de pouvoir basculer vers une autre branche.

De plus, si vous avez des modifications non validées sur votre branche actuelle, vous ne pouvez pas basculer vers une branche existante tant que vous n'avez pas commis les modifications sur votre branche actuelle.

Pour passer à une autre branche Git:

  1. Dans le projet, accédez au panneau Git Actions en cliquant sur l'icône Git dans le menu de gauche.
  2. Dans le panneau Git Actions (Actions Git), cliquez sur le menu déroulant de la branche Git à côté du nom de votre branche Git actuelle.
  3. Sélectionnez la branche que vous souhaitez utiliser en la sélectionnant dans le menu ou en saisissant le nom de la branche dans le champ de recherche. La recherche par nom de branche n'est pas sensible à la casse. Par exemple, vous pouvez rechercher "DEV" et afficher toutes les branches dont le nom inclut "dev", "DEV", etc.

Gérer les branches Git

L'onglet Branch Management (Gestion des branches) de la page Project Settings (Paramètres du projet) affiche un tableau de toutes les branches Git du projet Looker. Pour ouvrir l'onglet Branch Management (Gestion des branches), accédez à la page Project Settings (Paramètres du projet) en cliquant sur l'icône Settings (Paramètres) dans le menu de gauche, puis en sélectionnant l'onglet Branch Management (Gestion des branches).

Dans l'onglet Branch Management (Gestion des branches), vous pouvez:

  1. Créez une branche en cliquant sur le bouton Nouvelle branche. Pour en savoir plus, consultez la section Créer une branche Git sur cette page.
  2. Saisissez le nom des branches dans la barre de recherche.
  3. Actualisez la table en cliquant sur le bouton Actualiser.
  4. Triez le tableau en cliquant sur le nom d'une colonne.

Le tableau comprend les informations suivantes:

  • Name (Nom) : nom de la branche Git. Les branches personnelles des développeurs Looker commencent par dev-, et incluent le prénom et le nom du développeur.
  • État : différence entre votre version locale de la branche et sa version distante. Par exemple, l'état 3 commits behind signifie que votre version locale de la branche est derrière la version distante de la branche par trois commits. Comme Looker utilise toujours la version distante du maître, l'onglet Branch Management (Gestion des branches) n'affiche pas l'état de la version locale de la branche principale. La branche principale peut toujours être considérée comme à jour.
  • Dernière mise à jour: temps écoulé depuis qu'un développeur Looker a effectué un commit sur la branche.
  • Actions: bouton permettant de supprimer la branche ou raison pour laquelle la branche ne peut pas être supprimée.

Supprimer des branches Git

Dans l'onglet Branch Management (Gestion des branches), vous pouvez supprimer les branches qui comportent un bouton Delete (Supprimer) dans le tableau. Vous ne pouvez pas supprimer les branches suivantes:

Dans le tableau, ces branches ne comportent pas de bouton Supprimer. Au lieu de cela, la colonne Action du tableau indique la raison pour laquelle la branche ne peut pas être supprimée.

Vous ne pouvez pas restaurer une branche qui a été supprimée. Lorsque vous supprimez une branche, Looker supprime à la fois la version locale et la version distante de la branche.

Toutefois, si la branche a été créée par un autre développeur Looker ou si d'autres développeurs l'ont extraite, ces développeurs disposeront toujours de la version locale de la branche. Si un développeur Looker effectue des commits pour sa version locale de la branche et la transmet en production, vous verrez à nouveau une version distante de la branche. Cela peut être utile si vous souhaitez restaurer la branche. Sinon, lorsque vous supprimez une branche, tous les autres développeurs Looker doivent supprimer la même branche pour éviter qu'elle ne s'affiche à nouveau accidentellement lorsqu'un utilisateur la transfère à distance.

Pour supprimer une ou plusieurs branches Git de votre projet, accédez à la page Paramètres du projet en cliquant sur l'icône Paramètres dans le menu des icônes situé à gauche, puis en sélectionnant l'onglet Gestion des branches. Dans l'onglet Branch Management (Gestion des branches), vous pouvez supprimer des branches de deux manières:

  1. Supprimez plusieurs branches en cochant les cases correspondant aux branches, puis en cliquant sur Supprimer les branches sélectionnées.
  2. Supprimez une seule branche en cliquant sur Delete (Supprimer) à côté du nom de la branche.

Exécuter des commandes Git dans Looker

Looker dispose d'une interface intégrée qui s'intègre à votre service Git. Dans l'IDE LookML, un bouton pour Git s'affiche en haut à droite:

Le bouton Git affiche différentes options en fonction de l'étape à laquelle vous êtes en train d'apporter des modifications et de déployer l'application en production. En général, l'option affichée sur le bouton constitue la meilleure option pour la prochaine action.

Si votre branche développeur est synchronisée avec la branche de production, le message À jour s'affiche:

Une fois votre projet configuré pour Git, l'IDE affiche le panneau Git Actions (Actions Git), avec des commandes Git supplémentaires:

Les commandes disponibles dans le panneau Git Actions dépendent de l'état d'avancement du processus de modification et de déploiement en production.

Apporter vos modifications en production

Avec l'intégration Git par défaut de Looker, Looker invite les développeurs à suivre le workflow Git suivant:

Ainsi, avec l'intégration Git par défaut, tous les développeurs fusionnent leurs modifications dans une branche appelée master. Le dernier commit de la branche master est celui qui est utilisé pour l'environnement de production de Looker.

Pour les implémentations Git avancées, vous pouvez personnaliser ce workflow:

  • Vous pouvez demander à vos développeurs d'envoyer des demandes d'extraction pour votre branche de production Git, au lieu de les autoriser à fusionner leurs modifications via l'IDE Looker. Consultez la page de documentation Configurer les paramètres de contrôle des versions d'un projet pour en savoir plus.
  • Vous pouvez utiliser le champ Git Production Branch Name (Nom de la branche Git de production) pour spécifier la branche cible de votre dépôt Git que Looker doit utiliser comme branche cible dans laquelle vos branches Looker Developer sont fusionnées. Consultez la page de documentation Configurer les paramètres de contrôle des versions d'un projet pour en savoir plus.
  • Au lieu d'utiliser le dernier commit de la branche de production, vous pouvez utiliser le mode de déploiement avancé pour spécifier un nom de tag ou un SHA de commit différent à déployer dans votre environnement de production Looker. (Si vous souhaitez déployer un commit depuis une autre branche, vous pouvez utiliser le mode de déploiement avancé webhook ou le point de terminaison de l'API.) Pour en savoir plus, consultez la page Mode avancé du déploiement.

Si le bouton Configurer Git s'affiche à la place des options décrites dans cette section, vous devez d'abord configurer Git pour votre projet.

Afficher les modifications non validées

L'IDE LookML comporte plusieurs indicateurs qui s'affichent lorsque vous êtes en mode développement et que vous avez des modifications non validées, comme décrit dans la section Marquer des ajouts, modifications et suppressions de la page de modification et de validation de LookML.

Vous pouvez obtenir un récapitulatif des différences pour tous les fichiers à l'aide de l'option Afficher les modifications non validées du panneau Actions Git:

Dans la fenêtre Modifications non validées sur le projet, vous pouvez consulter un résumé de toutes les modifications non validées et enregistrées dans tous les fichiers du projet. Pour chaque modification, Looker affiche les éléments suivants:

  • Nom du fichier remplacé et nom du fichier ajouté.
    • Nom du fichier remplacé (indiqué par ---) et nom du fichier ajouté (indiqué par +++). Dans de nombreux cas, différentes versions du même fichier peuvent s'afficher, les révisions identifiées par --- a/ et +++ b/.
    • Les fichiers supprimés sont remplacés par des fichiers nuls (+++ /dev/null).
    • Les fichiers ajoutés remplacent un fichier vide (--- /dev/null).
  • Numéro de début de la modification.
    Par exemple, -101,4 +101,4 indique qu'à la 101e ligne du fichier, 4 lignes ont été supprimées et 4 lignes ont été ajoutées. Dans le cas d'un fichier supprimé comportant 20 lignes, -1,20 +0,0 indique que, sur la première ligne, 20 lignes ont été supprimées et remplacées par zéro ligne.
  • Texte mis à jour :
    • Les lignes supprimées s'affichent en rouge.
    • Les lignes ajoutées s'affichent en vert.

Vous pouvez également obtenir un récapitulatif des différences pour un seul fichier en sélectionnant l'option Afficher les modifications dans le menu du fichier:

Valider des modifications

Une fois que vous avez apporté et enregistré des modifications dans votre projet LookML, l'IDE peut vous demander de valider votre LookML:

L'utilisation de cette option dépend du paramètre de qualité du code de votre projet. Pour en savoir plus sur le programme de validation de contenu, consultez la page Valider votre lookML.

Si un autre développeur a apporté des modifications à la branche de production depuis la dernière mise à jour de votre branche locale, Looker vous demande d'extraire ces mises à jour de la branche de production:

Si votre projet est activé pour le mode de déploiement avancé, ce bouton indique Extraire de la branche principale.

Une fois que vous avez enregistré vos modifications (et corrigé les éventuels avertissements ou erreurs LookML, le cas échéant) et extrait la production (le cas échéant), le bouton Git affiche le message suivant:

Si vous le souhaitez, vous pouvez vérifier vos modifications non validées avant de les valider.

Lorsque vous êtes prêt à valider les modifications, utilisez le bouton Valider les modifications et les transférer pour les appliquer à votre branche actuelle. La fenêtre suivante affiche la liste des fichiers ajoutés, modifiés ou supprimés.

Saisissez un message décrivant brièvement vos modifications, puis décochez les fichiers que vous ne souhaitez pas synchroniser. Ensuite, cliquez sur Commit pour valider les modifications.

Rechercher des PDT non créés

Si vous avez modifié des PDT dans votre projet, il est optimal que tous vos PDT soient créés lorsque vous déployez en production. Ainsi, les tables peuvent être utilisées immédiatement en tant que versions de production. Avant de déployer vos modifications, vous pouvez vérifier que votre projet n'a pas été intégré dans le panneau Project Health (État du projet). Cliquez sur l'icône Project Health (État du projet), puis sur le bouton Validate PDT Status (Valider l'état du PDT).

Consultez la page de documentation Tables dérivées dans Looker pour en savoir plus sur la vérification des PDT non construites dans votre projet LookML et sur l'utilisation des tables dérivées en mode développement.

Exécuter des tests de données

Votre projet peut inclure des tests de données pour vérifier la logique de votre modèle LookML. Consultez la page de documentation sur les paramètres test pour savoir comment configurer des tests de données dans votre projet.

Vous devez être en mode développement pour pouvoir tester les données. Une fois en mode développement, plusieurs options s'offrent à vous pour lancer des tests de données pour un projet:

  1. Si les paramètres de votre projet sont configurés de manière à exiger que les tests de données soient concluants avant de déployer vos fichiers en production, l'IDE affiche le bouton Run Tests (Exécuter les tests) une fois que vous avez commis des modifications dans le projet. Tous les tests de votre projet seront exécutés, quel que soit le fichier qui définit le test. Vous devez réussir les tests de données avant de pouvoir déployer vos modifications en production.
  2. Cliquez sur le bouton Run Data Tests (Exécuter les tests de données) dans le panneau Project Health (État du projet). Tous les tests de données de votre projet seront exécutés, quel que soit le fichier définissant le test.
  3. Sélectionnez l'option Run LookML Tests (Exécuter les tests LookML) dans le menu du fichier. Seuls les tests définis dans le fichier actuel seront exécutés.

Une fois les tests de données exécutés, le panneau Project Health (État du projet) affiche la progression et les résultats:

  • Un test de données réussit lorsque l'assertion du test est vraie pour chaque ligne de la requête. Consultez la page de documentation sur les paramètres test pour en savoir plus sur la configuration des assertions et des requêtes de test.
  • Si un test de données échoue, le panneau Project Health (État du projet) fournit des informations sur la raison de l'échec du test, s'il a détecté des erreurs dans la logique de votre modèle ou s'il s'agit du test lui-même.
  • À partir des résultats du test de données, vous pouvez cliquer sur le nom d'un test de données pour accéder directement au LookML du test de données. Vous pouvez également cliquer sur le bouton Explorer la requête pour ouvrir une exploration avec la requête définie dans le test de données.

Déployer en production

Une fois les modifications validées dans votre branche, l'IDE Looker vous invite à fusionner vos modifications dans la branche principale. Le type d'invite que vous verrez dans l'IDE dépendra de la configuration de votre projet:

  • Si votre projet est configuré pour le mode de déploiement avancé, l'IDE vous invitera à fusionner vos modifications dans la branche principale. Une fois votre commit fusionné, un développeur Looker disposant de l'autorisation deploy peut déployer votre commit en production à l'aide du gestionnaire de déploiement Looker IDE, ou à l'aide d'un webhook ou d'un point de terminaison d'API.
  • Si votre projet est configuré pour l'intégration Git à l'aide de demandes d'extraction, vous serez invité à ouvrir une demande d'extraction à l'aide de l'interface de votre fournisseur Git.
  • Sinon, avec l'intégration Git par défaut de Looker, si vous disposez de l'autorisation deploy, l'IDE Looker vous invite à fusionner vos modifications dans la branche de production et à les déployer dans la version de production de votre instance Looker.

Mode de déploiement avancé

Avec l'intégration par défaut de Looker Git, les développeurs de Looker valident leurs modifications dans leur branche de développement, puis fusionnent leur branche de développement dans la branche de production. Ensuite, lors du déploiement dans l'environnement Looker, Looker utilise le dernier commit de la branche de production. (Consultez la section Obtenir vos modifications en production sur cette page pour connaître le workflow Git par défaut et les autres options pour les implémentations Git avancées.)

Si vous ne souhaitez pas toujours utiliser le dernier commit sur la branche de production de votre environnement Looker, un développeur avec l'autorisation deploy peut utiliser le mode de déploiement avancé pour spécifier le commit exact à utiliser pour votre environnement Looker. Cette fonctionnalité est utile dans les workflows de développement multi-environnement, où chaque environnement pointe vers une version différente d'un codebase. Cela permet également à un ou plusieurs développeurs ou administrateurs de mieux contrôler les modifications déployées en production.

Lorsque le mode de déploiement avancé est activé, l'IDE Looker n'invite pas les développeurs à déployer leurs modifications en production. L'IDE invite plutôt les développeurs à fusionner leurs modifications dans la branche de production. À partir de là, les modifications peuvent être déployées comme suit:

Pour en savoir plus, consultez la page Mode avancé du déploiement.

Vérifier l'impact de vos modifications

Une fois vos modifications mises à la disposition de l'organisation, vous pouvez utiliser la validation de contenu pour vous assurer que vous n'avez pas invalidé des tableaux de bord ou des looks enregistrés. Vous pourrez les corriger si vous l'avez fait.

Gérer les problèmes courants

Lorsque vous travaillez sur votre modèle, vous devrez peut-être:

  • Abandonner vos modifications

    Il peut arriver que vous souhaitiez abandonner vos modifications de modélisation des données. Si elles ne sont pas encore enregistrées, vous pouvez les actualiser ou quitter la page, puis accepter l'invite d'avertissement. Si vous avez enregistré les modifications, vous pouvez les annuler comme indiqué dans la section Annuler les modifications non validées.

  • Gérer les conflits de fusion avec d'autres développeurs

    Si plusieurs développeurs travaillent sur votre modèle de données, Git gère généralement la situation. Cependant, Git a parfois besoin d'une intervention humaine pour résoudre les conflits de fusion.

Certaines modifications, comme la modification du nom d'un champ, peuvent affecter les tableaux de bord et les styles existants. Comme indiqué précédemment, une fois vos modifications mises à la disposition de l'organisation, vous pouvez utiliser la validation de contenu pour vérifier vos contenus et résoudre les éventuels problèmes.

Annuler des modifications non validées

Lorsque vous travaillez sur votre branche de développement personnel, vous pouvez annuler les modifications non validées que vous avez enregistrées si vous ne souhaitez pas les déployer. Vous pouvez annuler toutes les modifications non validées pour tous les fichiers du projet ou uniquement pour un seul fichier.

Pour annuler les modifications non validées pour tous les fichiers :

  1. Cliquez sur l'option Rétablir dans le panneau Actions Git.
  2. Sélectionnez une option d'annulation :
    • Pour annuler uniquement les modifications non validées, sélectionnez Annuler les modifications non validées. Vous pouvez également cliquer sur le lien Afficher les modifications pour voir les modifications qui seront annulées.
    • Pour annuler toutes les modifications, y compris les modifications non validées et validées, sélectionnez Rétablir la version de production.
  3. Pour annuler, cliquez sur Confirmer.

Pour annuler les ajouts ou suppressions dans le contenu d'un seul fichier, sélectionnez l'option Annuler les modifications dans le menu du fichier:

Lorsque vous renommez un fichier, vous supprimez le fichier d'origine et en créez un autre avec un nouveau nom. Dans la mesure où plusieurs fichiers sont concernés, vous ne pouvez pas utiliser l'option Rétablir le fichier pour annuler le changement de nom d'un fichier. Si vous souhaitez annuler le changement de nom d'un fichier, utilisez l'option Rétablir dans le panneau Actions Git.

De plus, si vous avez supprimé un fichier, il ne s'affiche plus dans l'explorateur de fichiers IDE. Pour annuler la suppression d'un fichier, utilisez l'option Rétablir du panneau Actions Git.

Résoudre les conflits de fusion

En règle générale, Git peut fusionner automatiquement vos nouvelles modifications avec la version de production de vos fichiers LookML. Un conflit de fusion se produit lorsque Git ne parvient pas à déterminer les modifications à conserver. Cela se produit généralement lorsqu'un autre développeur a effectué des modifications depuis la dernière fois que vous avez récupéré des données et que vous avez effectué des changements dans la même zone. En cas de conflit de fusion dans votre code, vous recevrez un avertissement dans Looker une fois que vous aurez validé les modifications et extrait les données de production:

Lorsque Looker affiche l'avertissement concernant le conflit de fusion, il est recommandé de résoudre le conflit avant de procéder à d'autres modifications. Le transfert d'un conflit de fusion en production entraîne des erreurs d'analyse susceptibles d'empêcher l'exploration de vos données. Si vous êtes un utilisateur Git avancé et que vous souhaitez poursuivre les modifications, cliquez sur le bouton Ne pas résoudre.

Dans le fichier LookML, les lignes comportant des conflits sont marquées comme suit:

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

Looker affiche les repères de fusion suivants pour indiquer les conflits de fusion:

  • <<<<<<< HEAD marque le début des lignes en conflit.
  • >>>>>>> branch 'master' marque la fin des lignes en conflit.
  • ======= sépare chaque version du code afin que vous puissiez les comparer.

Dans l'exemple précédent, your code représente les modifications que vous avez validées, et production code représente le code dans lequel Git n'a pas pu fusionner automatiquement vos modifications.

Pour résoudre un conflit de fusion:

  1. Recherchez les fichiers présentant des conflits de fusion. Looker marque ces fichiers en rouge. Vous pouvez également rechercher dans votre projet des repères de fusion, tels que <<<< ou HEAD, pour identifier tous les conflits dans votre projet. Vous pouvez également trouver les fichiers concernés en cliquant sur le lien Fichiers dans l'avertissement de fusion qui s'affiche dans le panneau Actions Git.
  2. Dans le fichier, accédez aux lignes contenant des conflits de fusion, supprimez la version du texte que vous ne souhaitez PAS conserver, et supprimez également tous les repères de conflit de fusion.

  3. Enregistrez le fichier et répétez les étapes précédentes pour tous les autres fichiers marqués avec des conflits de fusion.

    CONSEIL : Recherchez dans votre projet chacun des repères de fusion pour vérifier que vous avez résolu tous les conflits et supprimé tous les repères de fusion. Veillez à supprimer toutes les instances des repères de fusion dans vos fichiers LookML. Ces repères provoquent des erreurs d'analyse susceptibles d'empêcher les utilisateurs d'explorer vos données.

  4. Une fois que vous avez résolu tous les conflits de fusion et supprimé tous les repères de fusion de votre projet, validez les modifications et déployez-les en production.

Maintenant que vous avez résolu le conflit de fusion et fait passer votre résolution en production, les autres développeurs peuvent effectuer une extraction depuis la production et continuer à travailler normalement.

Récupération de mémoire Git

La récupération de mémoire Git permet de nettoyer les fichiers inutiles et de compresser les révisions de fichiers pour optimiser votre dépôt Git. La récupération de mémoire Git (git gc) est exécutée automatiquement lorsque votre instance Looker est mise à jour ou redémarrée. Pour éviter d'exécuter git gc trop souvent, Looker attend 30 jours après le dernier git gc, puis exécute git gc au prochain redémarrage.

Dans de rares cas, vous pouvez essayer de transférer les modifications à distance ou de brancher la branche vers la télécommande lorsque git gc est en cours d'exécution. Si Looker affiche une erreur, patientez une minute ou deux, puis réessayez d'appliquer vos modifications.