Gestion de vos projets avec le contrôle des versions

Vous pouvez utiliser le contrôle des versions pour gérer le développement d'un projet de données et pour garder une trace des modifications.

Lorsque vous utilisez le contrôle des versions, vous pouvez valider (commit) des versions des projets lors de leur conception. Cela vous permet de voir les changements entre deux versions du projet. Vous pouvez également développer vos projets de données en utilisant une stratégie d'embranchement. Cela vous permet de travailler sur une version isolée du projet dans chaque zone de travail, ou branche. La zone de travail peut être partagée par plusieurs utilisateurs. Vous pouvez ensuite fusionner vos modifications de la zone de travail dans une branche principale à des fins de déploiement en production.

GitHub est utilisé comme fournisseur de contrôle des versions.

Prise en main

• Créez un utilisateur dans GitHub que le client peut utiliser pour accéder à GitHub. Il se peut qu'un administrateur l'ait déjà créé pour vous.

  L'utilisateur doit avoir les étendues suivantes :

  • repo

  • read:org

  • read:user

  • read:project

• Vous devez disposer d'un accès en écriture sur les référentiels que vous envisagez de modifier.

• Vous devez créer un jeton d'accès personnel (classique) GitHub. Les jetons d'accès personnels à grain fin ne sont pas supportés.

  Pour plus d'informations, consultez la documentation GitHub : Gestion de vos jetons d’accès personnels.

• L'organisation est obligatoire dans la configuration GitHub.

• Vous devez avoir le rôle Accès en écriture dans l'espace dans lequel réside le projet pour pouvoir effectuer des actions de contrôle des versions.

• Avant de pouvoir commencer à utiliser le contrôle des versions, vous devez effectuer une configuration pour pouvoir vous connecter à GitHub à l'aide de l'utilisateur GitHub que vous avez créé.

  Réalisation d'une configuration GitHub

• Lorsque vous avez établi une connexion à GitHub, vous pouvez connecter un projet à un référentiel.

  Connexion d'un projet à un référentiel

Réalisation d'une configuration GitHub

Tous les utilisateurs qui souhaitent utiliser le contrôle des versions doivent effectuer une configuration pour pouvoir se connecter à GitHub à l'aide d'un compte d'utilisateur GitHub.

Vous pouvez configurer GitHub dans Projets. Assurez-vous que vous vous êtes préparé conformément à la section Prise en main.

1. Cliquez sur , puis sur Configuration de GitHub.

2. Configurez l'authentification à l'aide de votre organisation et du jeton d'accès personnel GitHub décrit à la section Prise en main.

3. Cliquez sur OK.

Vous pouvez maintenant connecter vos projets à un référentiel.

Connexion d'un projet à un référentiel

Vous devez connecter un projet à un référentiel avant de pouvoir commencer à utiliser le contrôle des versions. Assurez-vous d'avoir établi une connexion à GitHub.

1. Dans Projets, cliquez sur ... sur un projet et sélectionnez Connecter au contrôle des versions.

2. Sélectionnez le référentiel auquel associer le projet.

3. Ajoutez un chemin d'accès au répertoire de base.

   Si vous souhaitez vous connecter à un projet existant dans GitHub, vous devez utiliser le même chemin d'accès.

4. Vous pouvez choisir de valider (commit) le projet et de pousser (push) le projet vers le référentiel distant après la connexion. Saisissez un message de validation.

   Si vous n'utilisez pas la fonction Commit et push, une branche principale sera créée dans la zone de travail, mais pas dans le référentiel distant.

5. Cliquez sur Se connecter.

Le projet est maintenant connecté au référentiel sélectionné. Cela est indiqué au bas de la fiche du projet par , le nom du référentiel et la branche active.

Lorsque vous ouvrez le projet, la ligne de titre contient maintenant un menu GitHub avec des options de contrôle des versions. Le nom de projet sera également complété par le nom de la branche active.

Développement d'un projet avec le contrôle des versions

Vous pouvez utiliser le contrôle des versions selon différentes approches :

• En travaillant directement sur la branche principale. Cette approche convient principalement à un seul développeur sur un projet pour lequel il souhaite garder une trace des modifications, mais elle peut également être utilisée par un groupe de développeurs qui travaillent de manière synchronisée.

• En appliquant une stratégie d'embranchement, qui permet la contribution de plusieurs développeurs. Vous pouvez également créer des branches pour isoler les nouvelles fonctions ou les modifications les unes des autres.

Flux de travail simplifié d'un projet impliquant un seul développeur

Vous pouvez travailler directement sur la branche principale d'un projet. Cette approche est plus simple et contient moins d'opérations, tout en vous permettant tout de même de suivre les modifications. S'il existe plusieurs développeurs, ils doivent veiller à être synchronisés.

Lorsque vous avez apporté au projet les modifications de votre choix il vous suffit d'appliquer Commit et push (Valider et pousser).

Flux de travail d'un projet impliquant plusieurs développeurs

Ce flux de travail peut être utilisé si plusieurs développeurs travaillent sur un projet ou si vous souhaitez isoler les modifications. Cela implique la création d'une branche de développement que vous pouvez partager avec d'autres utilisateurs. Grâce à ce flux de travail, les développeurs peuvent suivre les modifications des uns et des autres et décider du moment où elles doivent fusionner dans la branche principale.

1. Création d'une branche

   Créez une branche de développement à partir de la branche principale. Vous pouvez partager la branche avec d'autres utilisateurs.

2. Développement

   Apportez toutes les modifications nécessaires au projet.

   Note InformationsLes schémas et les connexions de base de données ne sont pas gérés dans le contrôle des versions.

3. Appliquer les modifications distantes

   Appliquez les modifications distantes d'une autre branche à votre zone de travail pour vous assurer que vous êtes à jour en intégrant les modifications de l'autre branche. Cela permet d'éviter ou d'atténuer les modifications contradictoires.

   Si vous avez deux branches contenant des modifications susceptibles d'entrer en conflit, une solution de contournement consiste à :

   1. Valider (commit) les modifications dans les deux zones de travail.

   2. Fusionner les deux branches dans la branche principale.

   3. Appliquer de nouveau les modifications distantes.

4. Commit et push

   La fonction Commit et push permet de valider et de pousser vos modifications dans la branche de développement. Tous les objets seront poussés ; il est donc judicieux de vérifier votre projet avant de le valider.

5. Ouverture d'une demande d'extraction et fusion

   Lorsque vous êtes prêt pour le développement, il est temps de fusionner les modifications de la zone de travail dans la branche principale. La fusion d'une branche de développement avec la branche principale doit être effectuée dans GitHub via l'ouverture d'une demande d'extraction (pull). Vous pouvez configurer l'approbation de la branche à fusionner avec la branche principale. Pour plus d'informations, consultez la documentation sur les demandes d'extraction (pull) GitHub.

Création d'une branche

1. Dans Projets, cliquez sur ... sur un projet et sélectionnez Créer une branche.

   Le projet doit être connecté au contrôle des versions.

2. Sélectionnez cette option pour créer une branche à partir de la branche principale.

3. Saisissez un nom pour la branche.

4. Définissez un préfixe à ajouter à tous les schémas du projet dans Préfixe de branche pour tous les schémas. Cela permet à tous les schémas d'être nommés de manière unique afin d'éviter les conflits de noms.

5. Cliquez sur Créer.

Une nouvelle branche est créée à partir de la branche principale et extraite du référentiel. La branche contient une nouvelle version du projet, avec toutes les tâches au statut Nouveau. C'est-à-dire qu'elles ne sont pas préparés et ne contiennent pas de données.

Application des modifications distantes

Vous pouvez appliquer les modifications du référentiel distant à votre zone de travail. Il peut s'agir de modifications créées en dehors du contrôle des versions intégré à Qlik Cloud, par exemple dans GitHub ou par d'autres outils. Cela vous permet d'éviter les conflits lorsque vous voulez appliquer la fonction Commit et push à vos modifications dans la branche.

1. Dans Projets, cliquez sur ... sur un projet et sélectionnez Appliquer les modifications distantes.

   Si des modifications ont été trouvées, la boîte de dialogue Appliquer les modifications distantes à la zone de travail s'affiche.

2. Vous pouvez maintenant sélectionner les tâches pour lesquelles des modifications doivent être appliquées et inspecter les modifications. Pour chaque modification, vous pouvez sélectionner la version à utiliser, la version distante ou la version de votre zone de travail.

3. Cliquez sur Appliquer les modifications distantes.

Vous devez ajouter des connexions sources et des connexions cibles, si les modifications incluent de nouvelles tâches de données.

Application de la fonction Commit et push

Vous pouvez appliquer la fonction Commit et push (Valider et pousser) à vos modifications dans la branche. Comme les modifications distantes qui ne sont pas appliquées à votre zone de travail peuvent être écrasées, vous devez Appliquer les modifications distantes avant de les valider et de les pousser.

1. Dans Projets, cliquez sur ... sur un projet et sélectionnez Commit et push.

   Si des modifications ont été trouvées, la boîte de dialogue Commit et push s'affiche.

2. Ajoutez un message de validation qui peut vous aider à garder une trace de ce qui a été modifié.

3. Cliquez sur Commit et push.

Suppression d'une branche

Vous pouvez supprimer une branche lorsque vous avez fusionné vos modifications avec la branche principale.

1. Dans Projets, cliquez sur ... sur la branche à supprimer et sélectionnez Supprimer la branche.

   Vous pouvez choisir de supprimer la branche distante également dans le contrôle des versions.

   En cas de modifications non validées, vous devrez accepter la perte de ces modifications lors de la suppression de la branche.

Retrait du contrôle des versions d'un projet

Vous pouvez déconnecter votre projet du contrôle des versions. S'il existe des branches, elles doivent être supprimées avant que vous puissiez déconnecter le projet.

1. Dans Projets, cliquez sur ... sur le projet à déconnecter et sélectionnez Déconnecter de GitHub.

Partage d'un projet avec d'autres espaces ou clients

Vous pouvez partager une version d'un projet avec un espace différent figurant dans le même client ou dans un autre client. Cette fonction est utile lorsque vous souhaitez créer deux environnements, par exemple un environnement de développement et un environnement de production.

1. Créez un projet portant le même nom que le projet d'origine.

   Définissez le même cas d'utilisation et le même type de plateforme. Vous pouvez utiliser des connexions différentes.

2. Connectez le nouveau projet au même référentiel et au même chemin d'accès au répertoire de base que ceux du projet d'origine.

   Note InformationsNe sélectionnez pas l'option Commit et push.

3. Si la connexion de la plate-forme pointe vers la même cible que celle du projet d'origine, veillez à modifier la base de données ou les schémas des tâches de données. Une façon de modifier les schémas de toutes les tâches consiste à modifier le Préfixe pour tous les schémas dans les paramètres Métadonnées du projet avant d'appliquer les modifications distantes. Cela garantit que toutes les tâches sont créées avec ce préfixe.

4. Appliquez les modifications distantes en sélectionnant tous les fichiers.

5. Ajoutez les connexions sources manquantes pour tous les tâches de dépôt temporaire.

   Cliquez sur Sélectionner des données sources dans la tâche de dépôt temporaire, sélectionnez la connexion et cliquez sur Enregistrer.

   Note InformationsLa connexion doit provenir du même type de source et pointer vers des tables portant les mêmes noms que ceux du projet d'origine.

6. Ajoutez les connexions sources et cibles manquantes pour tous les tâches de réplication.

Cela crée une autre zone de travail. Vous pouvez apporter des modifications au projet dans l'une des zones de travail et utiliser la fonction Appliquer les modifications distantes pour synchroniser l'autre zone de travail.

Considérations en matière de sécurité

Assurez-vous de maintenir les configurations de sécurité synchronisées entre Qlik Talend Data Integration et GitHub.

• Dans Qlik Talend Data Integration, les autorisations sont basées sur des espaces qui peuvent contenir plusieurs projets. Dans GitHub, les autorisations sont basées sur des référentiels qui peuvent également contenir plusieurs projets. La meilleure pratique consiste à les aligner et à connecter tous les projets d'un espace au même référentiel.

• Gardez à l'esprit que Qlik Talend Data Integration et GitHub utilisent des autorisations et des rôles différents pour les utilisateurs.

Bonnes pratiques

Voici quelques bonnes pratiques pour travailler sur des projets utilisant le contrôle des versions.

• Ajoutez un fichier LISEZMOI qui décrit le référentiel dans GitHub. Pour plus d'informations, consultez À propos des fichiers LISEZMOI.

• Ne validez (commit) que des projets valides et dont le fonctionnement a été testé.

  Si vous ajoutez des projets avec des tâches de données enregistrées ou de dépôt temporaire qui n'ont pas été préparées ou transformées, les colonnes sources ne sont pas encore incluses. Les colonnes sources sont ajoutées lorsque la tâche est préparée et transformée.

• Lorsque vous créez une branche pour des projets de réplication, vous devez savoir que les branches utilisent par défaut la même cible. Cela signifie que les tâches exécutées dans la branche peuvent remplacer les données de la version principale. Pour éviter toute perte de données, modifiez les paramètres cibles de la branche pour éviter tout conflit avec la version principale.

• Lorsque vous créez une branche, il se peut que des modifications distantes n'aient pas encore été appliquées à la zone de travail. Appliquez les modifications distantes avant ou après la création de la branche, à moins que vous ne souhaitiez les ignorer.

• Le fait d'apporter des modifications au même jeu de données dans deux branches différentes peut entraîner des conflits de fusion difficiles à résoudre.

Limitations

• Il n'est pas possible de déconnecter ou de supprimer un projet à l'aide du contrôle des versions s'il existe des branches. Les branches doivent être supprimées avant que vous puissiez déconnecter ou supprimer le projet.

• Il n'est pas possible de renommer un projet à l'aide du contrôle des versions.

• Lorsque vous supprimez un client, les objets stockés avec le contrôle des versions dans GitHub ne seront pas supprimés. Vous devez supprimer ces objets manuellement.

• Si un référentiel est utilisé par de nombreux projets ou s'il contient de nombreux fichiers qui ne sont pas stockés dans Qlik Talend Data Integration, les performances risquent de se dégrader.

• Les schémas et les connexions de base de données ne sont pas gérés dans le contrôle des versions.

• Les jetons d'accès personnels à grain fin GitHub ne sont pas supportés.

• Une branche (à l'exception de la branche principale) ne peut être utilisée que par un seul projet par référentiel, même si deux projets se trouvent dans le même référentiel.

• Il n'est pas possible d'appliquer des modifications distantes à partir d'un projet qui utilise une autre plate-forme cible. Par exemple, si vous validez (commit) des modifications apportées à un projet dans Snowflake, vous ne pouvez pas appliquer les modifications à un projet Databricks.