Ma définition
Les outils de versioning sont des systèmes de contrôle de version décentralisé, indispensable pour historiser le code, collaborer à plusieurs sur un même projet et faciliter les déploiements continus.
Mes éléments de preuve
Dans le cadre de la conception d’une architecture logicielle évolutive pour mon Mastère avec l’ISCOD, le travail nécessitait une rigueur absolue. C’est pourquoi j’ai mis en place un processus de « Git Flow » comprenant la séparation des branches main, develop et features) en gérant les fusions de code et en résolvant les conflits de manière systématique pour éviter l’écrasement du travail réalisé. Ce dépôt, hébergé sur GitHub sert également de point d’ancrage à la pipeline CI/CD. L’historique Git devient alors un élément fonctionnel de la chaîne de déploiement, et non plus seulement un outil de sauvegarde du code.
Résultat : Des temps de traitement réduits et des processus simplifiés permettant d’apporter une valeur ajoutée directe grâce à l’outil, un historique de commits propre facilitant le débogage rétrospectif, et une intégration directe et fonctionnelle avec la pipeline de déploiement automatisé.
Pour le projet « Dolibarr » réalisé dans le cadre de mon stage à Andil, j’ai utilisé GitLab en environnement professionnel pour la première fois en contexte d’entreprise pour récupérer les modules internes (notamment les plugins) mis à disposition par l’équipe de développement d’Andil. Cela était davantage orientée consommation d’un dépôt existant que contribution active à l’époque, mais qui m’a familiarisé très tôt avec les usages professionnels d’un gestionnaire de versions centralisé en entreprise.
Résultat : Des temps de traitement réduits et des processus simplifiés permettant d’apporter une valeur ajoutée directe grâce à l’outil.
Mon autocritique
J’estime avoir un niveau intermédiaire voire avancé sur cette compétence. C’est une compétence qui semble « invisible » pour le client final, mais cruciale pour un expert en ingénierie logicielle. Au départ, les commandes Git peuvent sembler abstraites, mais l’apprentissage se fait rapidement par la pratique et les deux projets mentionnés ci-dessus peuvent en attester.
Mon conseil sur ce point suite à mon expérience personnelle est le suivant: toujours rédiger des messages de « commit » clairs et explicites. Pour en avoir fait l’expérience par le passé, un message comme « correction bug » ne servira à rien à un collègue qui reprendra le code ultérieurement.
C’est un point qu’il ne faut surtout pas négliger et que je considère encore comme un axe de progression réaliste plutôt qu’une faiblesse : la théorie est bien entendu acquise, sa mise à l’épreuve dans un contexte d’équipe nombreuse reste à consolider en conditions professionnelles.
Mon évolution
À court et moyen terme, je souhaite dépasser la simple utilisation des commandes de versioning pour mieux maîtriser la création de pipelines CI/CD complexes en approfondissant les mécanismes déjà mis en œuvre précédemment (automatisation des tests et des déploiements lors d’un « push » sur le dépôt).
Je souhaite également renforcer ma pratique des mécanismes plus avancés du versioning distribué, la gestion fine des tags de version pour marquer des releases stables, et mettre en place des nouvelles règles de protection de branche (revue obligatoire avant merge sur `main`) des pratiques que je n’ai qu’esquissées sur trop peu dans un contexte personnel, mais qui deviennent indispensables dès qu’une équipe complète collabore sur un même dépôt.
C’est un axe que je compte creuser en priorité à l’avenir, car il conditionne directement la fiabilité d’une pipeline CI/CD : un historique Git mal maîtrisé se traduit tôt ou tard par des déploiements imprévisibles.