Accueil » git + synapse, gestion de version et de code source

git + synapse, gestion de version et de code source

git + synapse, gestion de version et de code source

Lors de tout projet informatique, nous avons pour habitude de mettre en place des outils et worklfow de développement pour sécuriser notre code et nos livraisons. Notre projet n’échappe pas à cette règle et il est important de mettre en place un gestionnaire de code source qui « sauvegardera » notre code et permettra de retracer les différentes modifications effectuées.

Tout n’est pas encore parfait dans le monde de la data, mais le minimum reste présent.

Nous allons ici mettre en place la version de code source avec git pour nos développements synapse.

Introduction

Lors de l’ouverture du studio synapse, en haut à gauche vous pourrez remarquer que nous sommes dans un mode « Synapse live ». (Si vous n’avez pas encore configuré le versionning évidemment)

Mode Synapse live

Ce mode « live » indique que nous travaillons directement (en live) sur les fichiers actifs de notre environnement. Autrement dit, si nous modifions un fichier de code qui est exécuté dans un pipeline, à la prochaine exécution notre modification sera exécutée. Si on est sur un environnement de production, cela revient à modifier du code source directement en production … Autant dire qu’en règle général, on ne souhaite ABSOLUMENT PAS faire ça !

De plus, outre la modification d’un code source en « live » nous n’avons pas non plus d’historique de nos modifications. Le code n’est pas versionné !!

Versioning ?

L’idée du versioning est d’enregistrer chaque modification de code/fichier afin de suivre l’évolution de celui-ci et d’être en mesure de revenir en arrière si nécessaire. Le versioning est très populaire dans le monde du développement informatique et nous ne rentrons pas en détail sur son mode de fonctionnement ici, mais globalement cela devient quasiment une obligation de nos jours. Plusieurs outils existent, mais git est les plus populaires et celui qui est couramment accepté de nos jours.

Git n’est pas particulièrement simple d’accès cependant lorsqu’il est utilisé à partir d’un gui ou de l’outil de développement, il ne devient plus nécessaire de comprendre le fonctionnement même de l’outil. (Même s’il est toujours important de s’intéresser au fonctionnement de nos outils !!).

Dans le monde git, nous parlerons de « repository / repo » qui pourrait correspondre à notre répertoire de source. D’ailleurs, lorsqu’il est vu depuis un système de fichier, un repo git correspond à un dossier contenant un dossier « .git » avec tout ce qui fait de ce répertoire un repository de gestion de version.

Le répertoire .git d’un repo

De nos jours un repo git est souvent hébergé sur un serveur distant (et maintenant le cloud via de nombreux services) qui correspond au repos « Origine » et chaque développeur possède une copie locale de celui-ci pour travailler. Nous opérons ensuite différentes synchronisations (commit/push/pull/…) pour que le code soit centralisé et partagé.

Plus d’info directement ici : Git (git-scm.com)

Création du repository

Un des prérequis à la mise en place du versionnions pour notre environnement Synapse est la création d’un Repository git. Dans notre cas nous allons travailler avec Azure DevOps qui est (avant le rachat de GitHub) la solution cloud privilégiée de Microsoft.

Nous allons supposer que nous avons déjà un compte et une organisation dans notre entreprise. Sinon il est toujours temps d’en créer une avec les 5 premiers utilisateurs « basic » gratuits. Rendez-vous sur le portail.

Nous arrivons sur la page de gestion de nos projets (car dans un projet on pourrait avoir plusieurs repos).

Portail Azure DevOps

Afin de rendre notre Lake indépendant, nous allons commencer par créer notre projet en cliquant sur le bouton approprié et en renseignant les quelques informations demandées. Pour le nom et la description, vous êtes libre. Cependant, sachez que le nom du projet sera utilisé dans les différentes URL de nos repos ou artéfact. De ce fait, j’évite les espaces et caractères spéciaux, mais ce n’est qu’une préférence personnelle (ça reste bien géré, mais votre URL comprendra les fameux %20 en cas d’espaces).

Pour la partie « Version control », il faut impérativement choisir « Git ». Et pour le « Work item process », c’est surtout utilisé pour la partie projet et n’a pas d’impact sur notre repository.

Création d’un nouveau projet

Notre projet créé, nous avons une myriade de nouveaux menus !

Page du nouveau projet

Nous n’allons pas faire le tour d’Azure DevOps, et ce qui nous intéresse principalement c’est la partie « Repos ». Il faut savoir que par défaut, un repos portant le même nom que notre projet est créé. En cliquant sur me menu « Repos », nous arrivons sur la page de ce nouveau repo vide que l’on nous propose de peupler.

Accueil du menu Repos

Personnellement, je n’utilise jamais ce repos et en crée un avec un nommage précis de ce pour quoi il va être utilisé. En l’occurrence, nous allons créer un nouveau repo « NiceDataLake_Synapse ». Pour ce faire, il faut cliquer sur le petit plus à côté du nom de notre projet pour créer un nouvel « artefact ».

Création d’un nouveau projet

Nous choisissons de créer un « new repository ».

Seul un nom est nécessaire.

Création du nouveau repo

A ce stade, notre repos est créé et opérationnel. Pour notre besoin dans Synapse, nous pouvons quitter Azure Devops, le reste se passe directement dans le studio.

Configuration du workspace

La 1re solution est de cliquer sur « Synapse live » qui est disponible sur les pages Data, Develop, Integrate ou Manage pour nous voir proposer la possibilité de mettre en place un repository git.

Démarrer la configuration de git

La deuxième solution est de passer par la page de Management de Synapse ou un sous-menu « Source control » est présent.

Management – Source control

Un nouveau panneau s’ouvre pour nous proposer le « type » de repository ou plus précisément l’hébergeur de notre repository. Les deux seules options disponibles sont Azure DevOps et GitHub tous les deux dans la galaxie Microsoft. D’où notre choix précédent de créer notre repo dans Azure DevOps. Point de bitbucket ou gitlab.

Choix de l’hébergeur de repository git

On nous propose de nous connecter à notre tenant DevOps. Deux cas de figure s’offrent à nous. Se connecter à un repository situé sur un autre tenant ou dans le même. Dans la grande majorité des cas, et ce sera le nôtre, nous nous connectons au même tenant et donc au même AAD qui sera rempli automatiquement. Louons malgré tout la possibilité de se connecter à un autre tenant en cochant la case approprié.

Choix du tenant de connexion pour Azure DevOps

Nous allons maintenant choisir quelle « organization » utiliser dans notre tenant Azure DevOps.

Puis nous pourrons choisir notre projet (créer précédemment).

Choix du projet

Ainsi que le repos précis à l’intérieur de notre projet.

Choix du repo

De nouvelles informations nous sont alors demandées qui vont configurer la façon dont notre Workspace va travailler avec notre repo git et les différentes branches.

Informations de branches git

Ce qu’il faut prendre en considération lors de la configuration de Synapse avec git est son mode de travail.

Configurations des branches

Nous allons commencer la configuration de nos branches. Si elles n’existent pas encore (car nous n’avons rien fait de notre repository lors de sa création), il est possible de les créer directement depuis cette interface en sélectionnant « Create new ».

Configuration du repo

Pour notre environnement de développement, nous allons créer notre première branche de collaboration de « dev ».

Création de la branche de collaboration

Pour rester cohérents, nous donnerons à notre branche de publication le nom de « dev_publish ».

Création de la branche de publication

L’option « Root folder » permet de définir un répertoire dans lequel seront posés nos fichiers sources. En le laissant vide, tout notre répertoire de travail sera déposé à la racine du repos. Ceci peut être utile si l’on veut déposer d’autres fichiers ou utiliser le repos pour une autre partie de notre projet. Dans notre cas, nous allons garder un repository uniquement pour nos développements avec Synapse et n’avons pas besoin d’utiliser un répertoire supplémentaire.

La dernière option nous propose d’importer nos développements actuels (si tant est que nous en avion déjà dans le Synapse Live, dans notre repository. Cette option permet de ne pas perdre les développements faits avant la configuration du versioning.

Dans notre cas, nous débutons nos travaux et nous n’avons pas besoin d’importer quoi que ce soit. Nous allons donc décocher cette option pour être sûr d’avoir un repo « clean ». Cependant, si vous avez déjà fait des premiers dev n’hésitez pas à importer vos développements dans votre repo en choisissant une branche de destination. La branche de collaboration est une bonne option pour qu’à votre démarrage, votre projet contienne l’état actuel de votre Synapse.

Notre configuration est maintenant faite, nous pouvons l’appliquer :

Configuration git finalisée

Lors de l’application, et lorsque vous vous connecterez à votre workspace synapse sans cookies, l’éditeur vous demandera sur quelle branche vous souhaitez travailler. Nous allons choisir notre branche de collaboration nouvellement créée « dev ».

Choix de la branche de travail

Notre workspace synapse est maintenant configuré pour travailler avec un repository git pour faire de la gestion de version.

Workspace configuré

Conclusion

Lors de nos prochaines visites dans notre environnement, nous aurons maintenant la possibilité de faire des commit de notre code (en gros de sauvegarder) et de « publier » notre code (le rendre actif) en utilisant les boutons suivants :

Une visite dans notre repository nous montre les premiers fichiers de notre Workspace créé par synapse.

Notre repository « clean »

Il est tout à fait possible de commencer à développer dans notre branche de collaboration (si l’on est seul à travailler ou pour des premiers tests) cependant il est plutôt recommandé de travailler avec un processus de gestion de branche de type « Feature branches ». Celui-ci sera expliqué dans un futur article.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *