Découvrir les bases du versioning et des repositories
Ce tutoriel montre comment utiliser le système de versioning natif de la Platform ou comment configurer un repository Git pour suivre les modifications de vos Data
Objectif
Ce tutoriel montre comment utiliser le système de versioning natif de la Platform ou comment configurer un repository Git pour suivre les modifications de vos Data Processing Actions.
Introduction
Prérequis
Pour suivre ce tutoriel, vous devez être familiarisé avec le Data Processing Engine et vous devriez idéalement avoir suivi le guide de Démarrage. L'essentiel est de savoir à quoi servent les Actions et comment les utiliser.
Aperçu des concepts
L'édition des actions est toujours en mode autosave. Lorsque vous essayez d'itérer sur des actions existantes, il est recommandé de créer plusieurs versions du code des actions. Cela vous permet d'introduire progressivement des variations pour expérimenter et tester votre travail, tout en gardant la version en production toujours intacte.
Sur la Platform, ce versioning se produit au niveau des repositories. Les repositories sont les onglets que vous voyez en haut de l'arborescence des Actions.
Vous ne pouvez pas versionner une action individuelle, mais tout un repository d'actions. Le panneau de versioning est accessible en haut à droite de l'en-tête du repository :
Il existe 2 systèmes de versioning sur la Platform :
- le système de contrôle de versions de la Data Platform : le système de versioning par défaut sur tous les repositories
- le versioning Git : si vous décidez de synchroniser votre repository avec Git
Voyons maintenant comment tout cela fonctionne en pratique !
Utiliser le système de contrôle de versions de la Platform
Par défaut, chaque repository d'actions sur la platform dispose d'un système de contrôle de versions intégré qui vous permet de gérer manuellement les différentes versions du code (c'est-à-dire des actions) qu'il contient.
Les repositories ont tous :
- une deployed version, qui est la version servie lors de l'exécution du job.
- une editing version, qui est la version en cours d'édition dans le panneau de l'éditeur.
Si votre repository n'a qu'une seule version, la version active est identique à la deployed version, ce qui signifie que vous éditez vos actions en production.
Si votre repository a deux versions ou plus, la deployed version ne peut pas être éditée. Elle peut être consultée en mode lecture seule.
Les versions doivent être créées manuellement. Pour créer une nouvelle version du repository, ouvrez le panneau de versioning en haut à droite et cliquez sur l'icône +.
Choisissez la version à dupliquer pour créer la nouvelle version.
Après la création de la nouvelle version, la deployed version ne changera pas. Vous pouvez éditer directement la nouvelle version.
Cliquez sur le bouton Play pour définir une nouvelle version comme deployed version : la version du code utilisée lorsque les actions du repo sont exécutées.
Utiliser un repository lié à Git
Chaque repository peut être lié à un repository Git externe, auquel cas les versions sont synchronisées avec les commits Git. Cela vous permet de mettre à jour et de tester les actions en continu sans affecter la version déployée en production.
Lier un repository à Git
Pour lier votre repository sur la platform à Git, vous devez cliquer sur l'icône en forme d'engrenage pour éditer un repository existant ou en créer un nouveau. L'une ou l'autre de ces actions ouvrira la fenêtre de configuration du repository.
Cliquez sur Connect to Git pour développer la fenêtre.
Ici, la première chose à saisir est l'URL SSH du Repository.
On la trouve généralement dans les options de clonage de repository des solutions Git courantes. Sur GitHUB, par exemple, elle se trouve dans Code > Clone > SSH.
Cliquez ensuite sur FETCH pour récupérer les branches distantes et sélectionnez la branche que vous souhaitez utiliser.
Enfin, copiez la clé SSH publique indiquée en bas et collez-la dans la liste des clés SSH associées à votre compte sur votre solution Git. Pour GitHUB, vous pouvez suivre ce tutoriel.
Committer et pousser
Après avoir modifié un objet dans un repo, votre repo affichera les changements non committés comme indiqué dans l'image ci-dessous. Vous pouvez les committer et les pousser en cliquant sur la flèche pointant vers le haut indiquée dans l'image.
En cas de conflit lors du push, vos changements ne seront pas poussés vers la branche que vous avez configurée ; ils seront à la place poussés vers une nouvelle branche portant le même nom que la branche actuelle avec un suffixe _conflictN, où N est le numéro du conflit. Par exemple, si votre branche s'appelle current-branch et que votre push provoque un conflit, la nouvelle branche s'appellera current-branch_conflict1. En cas de nouveau conflit lors d'un push suivant, la nouvelle branche s'appellera current-branch_conflict2.
Puller et merger
Récupérez les changements distants en cliquant sur la flèche pointant vers le bas indiquée dans l'image ; une fenêtre popup vous invitera à confirmer votre décision. Tous les changements non committés seront perdus et les deux branches seront fusionnées ensemble.
Aller plus loin
Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.
Posez vos questions, faites-nous part de vos commentaires et interagissez directement avec l’équipe qui développe la Data Platform sur le canal Discord dédié.
Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre centre d'aide.
Rejoignez notre communauté d'utilisateurs.