Un workflow Git efficace pour les projets à moyen/long terme

Une présentation d'un workflow Git testé et approuvé dans le cadre du développement, du déploiement et de la maintenance de produit GMAO JOB de Makina Corpus par une équipe de plusieurs développeurs.

Le blog Makina-corpus

Une présentation d'un workflow Git testé et approuvé dans le cadre du développement, du déploiement et de la maintenance de produit GMAO JOB de Makina Corpus par une équipe de plusieurs développeurs.

Notre projet de GMAO full-web est en développement depuis près de deux ans et est en production depuis plus de dix-huit mois. Je présente donc ici le workflow Git que nous avons utilisé et qui s'est montré très efficace jusqu'à présent.

 

Contexte

  • Plusieurs développeurs ;
  • Plusieurs instances de pré-production, plusieurs serveurs de production (versions de code non synchrones) ;
  • Releases mensuelles avec livraison en pré-production, puis sur le(s) serveur(s) de production ;
  • Sur les serveurs, la base de code est récupérée depuis le dépôt Git avec Fabric.

 

Règles

Pour gérer ceci, nous avons mis en place quelques règles simples :

  1. Un (et un seul) mainteneur, qui gère le dépôt Git et les releases ;
  2. Ne jamais commiter directement sur la branche master ;
  3. Ne jamais faire de rebase de master sur une autre branche ;
  4. Ne pas sortir du workflow prévu.

 

Workflow

Branche master

Notre branche master est le tronc commun et contient simplement toute la base de code de la prochaine release. Puisque nous ne commitons pas directement sur cette branche, elle n'avance quasiment que par des commits de merge.

Branches de développement

Quand un développeur commence une nouvelle fonctionnalité ou une correction de bug, il crée une nouvelle branche depuis le HEAD de master.

    
    $ (master) git checkout -b featureA
    $ (featureA) git commit -a -m "featureA part 1"
    $ (featureA) git commit -a -m "featureA part 2"

 

 

Le développeur suit l'évolution de la branche master et vérifie régulièrement que son code fonctionne toujours en faisant un rebase de sa branche de développement (featureA) sur la branche master.

     
    $ (featureA) git rebase master

Quand ses développements sont terminés (commits *fa1* / *fa2* dans le schéma ci-dessous), il fait un dernier rebase. Grâce à cela :

  • il s'assure que le mainteneur pourra merger son code facilement (le mainteneur ne doit pas avoir à lire le code en profondeur, ni à chercher pourquoi il y a un conflit ou un bug) ;
  • si les tests passent sur la branche de développement juste après le rebase, ils passeront aussi sur master, on s'assure donc que la branche master est toujours pleinement fonctionnelle.

Le mainteneur peut tranquillement merger cette branche dans master, sans problème de conflits. L'attribut --no-ff permet de forcer un commit de merge, ce qui permet d'avoir un historique parfaitement lisible (il est facile de voir où une branche a commencé et où elle a été mergée).

    $ (master) git merge --no-ff featureA



Une fois sa branche de développement mergée, il est préférable que le développeur la supprime :

    $ (master) git branch -d featureA
    $ (master) git push origin :featureA

 

Branches stables

Préparer une release revient à mettre à jour le fichier CHANGELOG (avec ce workflow, la commande git log --oneline donne un résumé assez clair et concis), tagger la branche master (optionnel) et démarrer une nouvelle branche stable.

    $ (master) git tag 1.0
    $ (master) git checkout -b stable1.0
    $ (stable1.0) git push origin stable1.0

Note : Le tag et la branche ne doivent pas porter le même nom.

Cette branche stable est déployée sur les différents serveurs.

Pendant que les développements avancent, il peut être nécessaire de réaliser des corrections urgentes (commit hf1 dans le schéma ci-après), qui doivent être déployées en production rapidement. Ces corrections sont faites directement sur la branche stable concernée, ce qui assure de n'avoir aucun commit qui descende de master vers une branche stable de manière incontrôlée.


Régulièrement, le mainteneur merge la branche stable dans master pour récupérer ces commits de correction. Cette action est particulièrement importante avant la release suivante.

    $ (master) git merge --no-ff stable1.0

Cette méthode s'est montrée très efficace et très fiable car :

  • chaque branche stable a sa propre vie et n'est pas impactée par l'évolution de master. Il est donc possible de réaliser des corrections très rapidement sans se préoccuper des développements réalisés depuis la dernière release ;
  • il est assuré qu'aucune correction n'a été perdue avant la release suivante, ce qui évite les régressions.

 

Un exemple plus complet d'historique



Conclusions

Bien sûr, il y a de multiples workflow Git qui peuvent se montrer efficaces, mais nous avons trouvé beaucoup d'avantages à travailler avec celui-ci, sans avoir eu de réel problème :

  • La branche master est toujours propre et fonctionnelle ;
  • Les développeurs n'ont pas à se préoccuper du workflow Git complet ;
  • Des corrections peuvent être déployées rapidement, sans stress ;
  • Chaque release stable contient les nouvelles fonctionnalités et les éventuelles corrections ;
  • Travailler dans des branches systématiquement et utiliser l'option --no-ff permet d'avoir un historique vraiment clair ;
  • Ce workflow est évolutif (un accroissement du nombre de branches ou de développeurs n'a pas vraiment d'impact).

 

Restons connectés !

 

Offre de formation GIT

Makina Corpus dispose d'experts GIT, vous pouvez retrouver notre formation GIT ou nous contacter.

Formations associées

Outils et bases de données

Git, gestionnaire de versions

A distance (foad) Du 4 au 5 octobre 2021

Voir la formation

Actualités en lien

20/07/2021

Accéder à sa base de données PostgreSQL depuis QGis ou pgAdmin de manière sécurisée

Comment interconnecter ses outils de travail sans mettre en péril la sécurité du système informatique ? L’objectif de cet article est de présenter une manière sécurisée de connecter QGis ou pgAdmin à une base de données PostgreSQL, afin d’atteindre le meilleur compromis entre praticité et sécurité.

Voir l'article
03/07/2020

Webmapping : comparaison des serveurs de tuiles vectorielles depuis Postgres / PostGIS

Un ensemble de serveurs de tuiles vectorielles basés sur la fonction ST_AsMVT() de PostGIS sont disponibles. Makina Corpus vous propose un tour d’horizon des spécificités des différentes solutions.

Voir l'article
28/01/2020

Paralléliser des requêtes avec PostgreSQL

PostgreSQL permet de découper les requêtes pour en exécuter des parties en parallèle. Il faut toutefois en connaître les concepts pour pouvoir en bénéficier au mieux et ne pas empêcher le planificateur de requêtes de le faire.

Voir l'article

Inscription à la newsletter

Nous vous avons convaincus