Aller à la navigation

Blog

Retour à l’accueil

20 Jan 2022

Cinq pratiques à éviter avec Git… ou tout autre SCM !

Par Avi EL KHARRAT, Ingénieur DevOps FINAXYS

On est bien d’accord, la pratique DevOps vise à améliorer la productivité des équipes de dev. Le Time-To-Market se réduit grâce à la mise en place de procédés fluides et automatiques. Pour l’intégrateur qui avant compilait, packageait et livrait à la main, c’est une véritable libération ! Il utilise à présent sa matière grise pour modéliser l’activité de son équipe en concevant des jobs ou en écrivant des scripts qui décrivent des infrastructures… Quelle merveille que l’automatisation des procédés !

Cela-dit, au-delà de l’automatisation, une profonde réflexion doit être menée sur ces procédés eux-mêmes, de manière à mettre en évidence les étapes inutilement chronophages ou celles qui génèrent le plus de frustration. Dit autrement, automatiser un procédé mal conçu ne peut pas répondre aux objectifs d’amélioration. 

Le présent article tente de mettre en évidence cinq pratiques que l’on rencontre fréquemment dans les workflows de développement et qui génèrent beaucoup de frustrations sans améliorer les performances de l’équipe, bien au contraire. Il s’agit de pièges et de fausses évidences dans lesquels il peut être facile de tomber !

Ce qui suit est le résultat d’observations effectuées au cours d’expériences de terrain. C’est pourquoi nous allons nous concentrer non pas sur les détails techniques mais sur la stratégie de gestion du code. Pour chaque cas, nous identifierons la mauvaise pratique et chercherons à donner des pistes de réflexions pour la rectifier.

Git étant très tendance, c’est lui qui sera pris comme exemple comme SCM. Bien que la plupart des cas évoqués sont facilement généralisables à d’autres outils ou d’autres pratiques du même type.

Le workflow de dev est l’œuvre d’une seule personne

Le constat

Le workflow de développement est l’œuvre d’une seule personne, sans concertation avec l’équipe de dev. Il arrive même que le concepteur du workflow soit extérieur à l’équipe de développement.

Le risque est que, au travers de ce workflow, son auteur ne s’attelle qu’à résoudre les problématiques qui le concernent sans forcément prendre en compte celles des autres membres de l’équipe.

Les développeurs pourraient alors se retrouver dans des situations aberrantes, tel que demander des validations à des personnes ne pouvant évaluer ni l’urgence ni la criticité de leur demande.

Le conseil du coach

Laisser l’équipe de développement mettre en place son propre workflow de façon émergente. Commencer par implémenter un workflow simple afin de le faire évoluer au fur et à mesure des expériences de l’équipe, les succès étant aussi importants que les échecs. Les rétrospectives sont le moment idéal pour aborder ces sujets, sinon les réunions techniques.

L’avantage d’une telle pratique est que l’équipe de dev, se sentant plus impliquée dans l’élaboration du workflow, sera plus enclin à l’appliquer proprement et à le faire évoluer. La montée en compétence des nouveaux arrivants s’en trouvera également facilitée.

Mettre en place un workflow trop contraignant

Le constat

Le workflow de développement comporte trop de statuts et de validations qui le ralentissent. Le workflow de développement est trop fortement couplé au workflow des users stories. Pour faire avancer les développements vers la production, il faut suivre une succession d’étapes très strictes et très complexes. En particulier, la mise à jour des statuts des user stories, ce qui n’est pas toujours faisable par un développeur.

Si la plupart de ces actions sont probablement nécessaires à la bonne santé de l’application, le fait de les lier fortement risque tôt ou tard de devenir un gouffre temporel.

La raison en est que ce type de synchronisation n’est bien souvent adapté qu’au seul cas d’usage pour lequel il a été conçu. Or, il est tout à fait probable (peut-être même inévitable) que d’autres cas émergent avec le temps. Dans ces circonstances, on observe alors les comportements suivants :

  • L’équipe accepte le fait que le workflow ne soit pas adapté à la situation et que du temps soit perdu inutilement ;
  • L’équipe contourne les lourdeurs du workflow en créant de fausses tâches de développement, des évènements ne correspondant à rien, ou valide des artéfacts fantômes…
  • L’équipe sort purement et simplement du workflow de développement.

Il est d’ailleurs étonnant de constater que rares sont les équipes qui remettent en question le workflow lui-même et qui cherchent à le faire évoluer.

Le conseil du coach

Git empêche de créer des commits qui n’ont pas de commentaire. De plus, il est possible d’imposer un format à ces commentaires. Le plus courant est d’obliger les commentaires à commencer par un numéro de tâche, un identifiant d’user story. C’est au mieux ce qu’il est possible d’imposer en termes de contraintes à ce niveau.

Toutefois, il faut être rigoureux sur la clarté des commentaires des commits : exiger de ses développeurs des phrases claires et explicites en plus du numéro de la tâche à laquelle le dev est rattaché.

Une autre méthode très pratique dans Git (mais plus difficile à maitriser sans les outils adaptés) est de fusionner les commits entre eux. Cette méthode permet d’agréger une série de commits consécutifs ce qui est particulièrement pratique pour rassembler tous les commits à une même user story.

Toutes ces pratiques sont largement suffisantes pour faire le lien entre des users stories et des développements.

Par ailleurs, il est possible de mettre en place une CI la plus complète et la plus automatique possible. Cet effort permettra d’identifier les lourdeurs, les redondances et les incohérences du workflow de développement.

Ici encore, il est préférable de faire appel à l’intelligence collective de son équipe pour affiner ces conventions et les inciter à les mettre en place. Ne pas hésiter à afficher des posters explicatifs de ces conventions.

Mal définir la stratégie de branchage

Le constat

A l’opposé d’un workflow trop contraignant, un workflow trop permissif ou mal défini risque également de ralentir l’équipe. L’absence de consensus sur les règles des noms attribués aux branches, de fusion et de nettoyage, sera source de confusion et d’erreurs au sein de l’équipe.

Le conseil du coach :

Il est primordial de définir et d’identifier clairement chaque branche par rapport à son utilité, sa raison d’être initiale. S’agit-il d’une branche de développement de fonctionnalité, d’un bug-fix, d’une expérimentation… ?

Une des grandes forces de Git réside dans la gestion des branches. C’est sur cette fonctionnalité qu’il faut appuyer son approche.

Pour commencer, imposer des noms de branches clairs qui intègrent des informations relatives aux users stories ou aux dates de release.
Par exemple : feature/ABC-123 pour les développements, fix/DEF-456 pour les corrections à chaud, release/202109 pour les branches de release… Cela facilitera l’insertion du code porté par ladite branche sur la branche commune.

Définir une stratégie de branchage / fusion claire et adaptée. Commencer par prendre connaissance des différents modèles de workflow standards (Git Flow, Github Flow, Trunc Based Development…).

Parmi ces modèles, sélectionner celui qui se rapproche le plus de ses pratiques en ne prenant en compte que les cas d’usage les plus fréquemment rencontrés (il ne doit pas y en avoir tant que ça).

Procéder aux adaptations nécessaires, tant dans le modèle de workflow standard que dans le workflow de développement.

S’assurer que la sémantique des différentes branches est bien maîtrisée par les membres de l’équipe, en particulier celles portant l’activité de l’équipe et celles portant les versions de production. Cette dernière recommandation est particulièrement importante en cas d’utilisation de Git Flow.

La méthode de fusion des branches doit être particulièrement claire et connue de chacun.

Définir clairement ses Pull Requests (ou Merge Request avec Gitlab) et les critères de recevabilité d’un nouveau développement, d’un bug fix (s’il diffère), y compris toutes les validations effectuées par jobs automatiques (la fameuse CI). Si certains « passe-droits » sont tolérés (misère, misère…) cela doit également être spécifié dès le départ.

La politique de nettoyage des branches doit également faire partie des points d’attention. Il faut partir du principe qu’une branche de développement doit être supprimée dès qu’elle est fusionnée sur la branche principale. Favoriser les tags à la rétention des branches de release.

Pour finir, faire un schéma du workflow final (sans entrer dans les détails) et l’afficher en grand format dans l’open-space de l’équipe.

Utiliser Git en mode Ninja

Le constat

En tant qu’ingénieurs, nous avons souvent tendance à trouver des réponses complexes à des problématiques simples, pour se prémunir à toutes les éventualités mêmes aux plus improbables. Ce faisant, nous augmentons la complexité des systèmes que nous créons et la difficulté de les appréhender. Les workflows de développement n’échappent pas à ce biais.

De surcroit, Git est une application qui demande une certaine pratique pour être convenablement utilisée. Il n’est pas rare que des débutants soient perdus ou embrouillés dans un pull mal maîtrisé. L’auteur de cet article en a d’ailleurs déjà fait l’expérience ! L’interface de commande de Git n’est pas des plus intuitives et certaines fonctionnalités très avancées peuvent être dangereuses… A ses risques et périls !

Le conseil du coach

Il fallait bien le placer dans un article sur les bonnes pratiques Git : restez KISS – Keep It Simple & Safe !

Eviter les workflows inutilement compliqués. Opter pour la solution la plus simple qui s’offre à vous, ou tout du moins, lui laisser une chance avant de se lancer sur la solution la plus sophistiquée.

La complexité arrive tôt ou tard, même lorsqu’elle n’est pas invitée. Bien souvent, elle arrive là où on s’y attend le moins. Laisser donc l’expérience guider et faire émerger les véritables besoins en complexité au fur et à mesure.

De plus, un workflow complexe nécessite peut-être l’utilisation de commandes Git difficiles à maîtriser. Sur le plan technique donc, se fixer comme point de repère le « Pull-Rebase et Push Force sur une feature branch » comme limite à ne pas dépasser. S’il nous arrivait d’utiliser des fonctionnalités avancées de Git, posons-nous honnêtement la question du bien-fondé de cette action.

Lier des branches de développement à des environnements de test

Le constat

De bien des façons le statut du code est représenté par la branche qui le porte : sur la branche feature, le code est en cours de développement ; sur la branche master, il est en cours d’assemblage ; sur la branche de release, il est en cours de stabilisation pour la production.

Cependant, chercher systématiquement à lier le statut du code à sa branche entraînera sans nul doute une augmentation dangereuse de complexité du workflow, comme cela a été évoqué dans le paragraphe précédent. Le sommet de l’anti-pattern est lorsque les environnements sont asservis aux branches portant le code fonctionnel et le point culminant est atteint lorsqu’il est nécessaire de créer des user stories pour être en mesure de créer ces branches.

Qu’il s’agisse d’environnements éphémères ou permanents, le fait de lier des environnements à des branches de développement provoquera nécessairement des situations aberrantes. Comme par exemple être obligé de créer artificiellement des branches (et pourquoi pas des US) pour provisionner un environnement, ou pousser le code sur une branche spécifique pour le voir se déployer sur l’environnement lui étant associé. Nous sommes là aux antipodes de l’architecture hexagonale.

De plus, cette pratique favorise la prolifération de branches. Le projet risque de devenir rapidement une véritable forêt vierge que personne n’osera venir nettoyer de peur de détruire un écosystème qui pourrait être utile.

Le conseil du coach

Tout d’abord, de quoi parle-t-on ici ?
Nous vous déconseillons de lier les environnements aux branches portant le code fonctionnel. Il est bien évident que le code d’infrastructure (IAC) et de déploiement doit contenir des informations concernant son environnement et sa configuration, qu’il soit éphémère ou permanent !

Le principe de l’architecture hexagonale est de complètement désolidariser le code fonctionnel de tout autre code. De cette manière, le code fonctionnel peut être porté par un binaire totalement agnostique de l’environnement technique et infrastructurel sur lequel il est déployé. On retrouve ici le principe « compile une fois, exécute partout » qui est un des fondements du langage Java et qui a été repris par les technologies de conteneurisation et d’orchestration de conteneur (Docker et Kubernetes pour ne citer qu’eux).

Ainsi, le code a une structure en oignon : une première couche de code fonctionnel, puis une couche de code technique, puis encore une couche de code d’infrastructure et enfin une couche de déploiement. Les informations concernant les environnements doivent être contenues dans les couches d’infrastructure et de déploiement, mais jamais (au grand jamais !) dans les couches fonctionnelles et techniques et certainement pas asservies à elles.

Evidemment, les couches d’infrastructure et de déploiement sont, quant à elles, très fortement liées. Mais ce lien peut-être créer au travers d’un contrat d’interface et non par une intrication forte.

Le mot de la fin

En conclusion, les problématiques évoquées proviennent souvent de la même origine : une mauvaise gestion des contraintes et des couplages ; et la solution est bien souvent aussi la même : faire appel à l’intelligence collective de son équipe, et faire émerger les patterns en fonction des expériences plutôt que de les établir à priori.

Si vous êtes à actuellement dans l’une des situations décrites plus haut, il se peut que vous ayez l’impression de jouer au mikado : le workflow est si intriqué qu’y modifier quoi que ce soit pourrait avoir des répercussions néfastes sur l’ensemble du projet.

Alors, comment s’y prendre ?

Tout d’abord, expérimentez sur des projets de moindre importance ou sur ceux qui démarrent. Il est important de monter en compétences sur Git et de comprendre ce que cette application permet de faire avant de se lancer sur des projets plus critiques.

Profitez de l’effort d’automatisation pour revoir la façon dont vous gérez votre code.

Faites du nettoyage et du rangement ! Vous n’imaginez pas ce que les projets informatiques paressent plus simples lorsqu’ils sont débarrassés de tout ce qui leur est inutile et lorsque chaque chose est à sa place. Cet exercice vous permettra, en outre, d’en avoir une meilleure vision d’ensemble.

Parlez à vos collègues de votre volonté d’assainir le workflow de développement. Et bien évidemment, entourez-vous de professionnels qui ont plus d’expérience en la matière.

Bonne utilisation de Git ! 😊

Share our news :

-