Comme mentionné dans un précédent billet, chez SRMvision, nous utilisons intensivement les features branches pour isoler nos développements et nous permettre de basculer facilement une fonctionnalité en production avec un historique clair des modifications.

Une des pratiques que nous avions mis en place depuis le début (à l’époque ou nous utilisions subversion) est l’interaction avec notre gestionnaire d’incidents (Trac) depuis nos commits. Ainsi, nous utilisons les commandes suivantes dans nos messages de commits (des synonymes existent, mais nous les utilisons peu) :

• see #NUM pour référencer un ticket
• fix #NUM pour clore un ticket

Les références vers les commits concernés sont donc intégrées automatiquement dans l’historique des tickets sur Trac.

Pour s’assurer de la qualité de nos développements, nous avons mis en place un workflow personnalisé dans Trac. Une fois un développement / bugfix terminé, nous passons le ticket le concernant en statut “Testing”. Le résultat est simple, soit le test est concluant et le ticket est clos, soit il ne l’est pas et il retourne donc au développeur. Ainsi, aux commandes décrites précédemment, nous avons ajouté la possibilité de passer un ticket en test en mettant la commande “test” dans nos commits.

Le fait d’avoir maintenant beaucoup de branches nous a conduit à repenser notre façon de fonctionner pour avoir un contrôle plus efficace des tickets. En effet, contrôler le workflow des tickets pour les passer en test alors qu’ils ne sont pas encore sur la branche “recettable” a commencé à introduire plus de bruit sur Trac que de bénéfices réels. Nous avons donc rajouté un statut “Fixed on branch” nous permettant de différencier les tickets réellement testables de ceux qui ne sont pas encore prêts.

Après quelques hésitations, nous avons fini par obtenir le mécanisme suivant, tout en gardant les mêmes trois verbes principaux (see, fix, test) :

• Lors d’un commit incluant le verbe “test” sur une branche autre que le master, le statut du ticket est passé à “Fixed on branch” et le ticket est clos.
• Lors du merge de la branche sur le master, les tickets “Fixed on branch” sont automatiquement repassés en “Testing”
• Le comportement sur la branche master reste identique

Sur un développement de fonctionnalité classique, nous pouvons avoir 50 tickets “Fixed on branch” qui se réouvrent automatiquement en “Testing” lors du passage de la fonctionnalité sur le master. Cette technique nous permet de suivre facilement le développement d’une fonctionnalité de sa réalisation à sa livraison.

Si vous désirez mettre en place un mécanisme similaire dans votre environnement, les fichiers que nous utilisons sont disponibles à l’adresse suivante : https://github.com/CedricGatay/sandbox/tree/master/trac-git-hook

Vous trouverez les trois fichiers suivants:

• post-receive : hook git à proprement parler, à placer dans le dossier hooks/ de votre dépôt central, déclenche le lancement différé (1 minute plus tard) du script suivant (pour éviter de bloquer le commit),
• trac-post-commit-hook : hook trac effectuant le traitement des messages de commit pour intéragir avec les tickets
• trac.options.ini : extrait du fichier de configuration Trac permettant de personnaliser le workflow des tickets

Notez qu’il sera certainement nécessaire de modifier les variables des scripts python permettant de référencer le dépôt git dans Trac (dans notre cas il est nommé git-clone), ainsi que les chemins utilisés dans votre environnement.