Hipchat au service des processus de développement de Nomad Suite


Publié par
Julie d'ANTIN

27 mars 2014

Pour une équipe développant un produit innovant, le travail collaboratif représente un véritable enjeu. Si chacun avance dans son coin, c’est la catastrophe assurée. Si l’équipe multiple les meetings, c’est un temps précieux pour le projet qui est gaspillé, et peut-être une fonctionnalité clef qui sera reportée.

Les outils Atlassian, tels qu’Hipchat offrent aux équipes agiles et exigeantes sur la qualité de leurs produit une vrai solution collaborative. Dans cet article, nous avons invité Joel Cogen & Stephane Amant de Belighted à nous partager les outils que leurs développeurs  utilisent pour travailler efficacement ensemble.


Depuis quelques mois chez Belighted, nous sommes tous engagés dans ce qui pourrait être une percée dans le monde des progiciels de gestion intégré (ERP). Nous réalisons ce défi en utilisant les derniers outils à la pointe de la technologie tel quel AngularJS et bien d’autres !

Pour relever ce challenge créatif de développement d’une nouvelle application mais aussi et avant tout en matière de travail collectif, nous avions besoin de mettre en place un processus de travail aussi complet que possible qui nous permettrait de produire un code de grande qualité tout en assurant sa traçabilité, mais aussi simple et souple afin de nous concentrer uniquement sur l’implémentation des fonctionnalités de notre solution logicielle.

Afin de rendre les tâches aussi fluides que possible pour l’ensemble de l’équipe, nous avons donc fait confiance à quelques excellents outils et les avons intégrés les uns aux autres pour automatiser au maximum ce qui pouvait l’être.

Débuter le développement d’une fonctionnalité

Comme c’est le cas pour n’importe quel projet agile, les fonctionnalités de Nomad Suite sont décrites au travers d’histoires (User stories), ordonnées par priorité de réalisation, via le populaire Pivotal Tracker.

La première étape est donc de démarrer la première story présente dans le backlog. Ce qui permet ainsi à toute l’équipe de savoir qui travaille sur quoi. De plus, étant donné que nous utilisons HipChat comme outil de communication interne et que nous avons connecté les deux outils ensemble, toutes les parties prenantes au projet sont également automatiquement averties.

deals

development

Ensuite, nous créons une nouvelle branche pour contenir le code lié au développement de cette fonctionnalité (feature branch). Cette branche doit être nommée de manière claire et concise afin de ne permettre aucune confusion pour les autres développeurs une fois publiée. Certains d’entre nous préfèrent ajouter l’identifiant de la story provenant de Pivotal, mais nous n’avons pas de modèle bien défini. Les feature branches sont extrêmement importantes pour nous étant donné qu’elles nous permettent d’expérimenter à volonté, de créer des commits et de les partager, de revenir en arrière si besoin, tout cela sans perturber le travail des autres et, encore plus important, sans impacter les environnements de test et de production.

A de rares occasions, nous créons des commits directement sur la branche master, mais ces modifications doivent alors respecter deux conditions:

  • Elles ne nécessitent pas d’être examinées par un autre développeur. Ceci étant vrai pour de petites erreurs de code ou de typographie, des changements de paramètre mais pas plus.
  • Elles doivent être suffisamment triviales pour que, si vous êtes interrompu, vous puissiez facilement les mettre en attente ou les effacer avant de les poursuivre à votre retour.

Système de rapport en continu

Lors de chaque publication sur GitHub, l’équipe reçoit une notification via HipChat. Il s’agit là d’un très bon moyen de tenir au courant quiconque est intéressé par la progression du développement d’une fonctionnalité.

report-1

Notre serveur d’intégration continue, Semaphore, est également averti, et communiquera ensuite, via HipChat (comme vous auriez pu vous en douter), si l’application passe tous les tests. Ceci permet aux développeurs de ne pas devoir lancer la suite de tests dans son intégralité (étant donné que certains de ceux-ci prennent plusieurs minutes). Dès lors, il est parfaitement admissible que certains de ces tests échouent sur unefeature branch.

report-2

Finitions

Une fois la fonctionnalité implémentée, testée, et que tous les tests passent, la branche contenant celle-ci est prête à être incluse dans la branche master.

Mais peut-être pas encore : il est plutôt l’heure de prêter attention aux différents commits qui la constituent et de les réduire en un seul si nécessaire.

Comme pour le nom des branches, nous n’avons pas de règles explicites à propos des commits et des messages, mais voici cependant quelques exemples de ce que nous détestons voir (allant de pis en pis):

  • Fonctionnalités incomplètes (ou non fonctionnelles)
  • Fonctionnalités non testées
  • Tests ne passant pas
  • « wip »

Tous les commits doivent faire référence à l’identifiant d’une story provenant de Pivotal Tracker et le dernier doit indiquer qu’il termine le développement de telle manière que GitHub puisse mettre à jour le tracker pour nous. La story est maintenant automatiquement marquée commeterminée, mais nécessite encore d’être revue. Il est temps d’ouvrir une demande de requête de fusion du code (Pull request) sur GitHub.

github

Revue du code

Parce que nous voulons être certains que le code produit est le meilleur que nous pouvons écrire, et parce que nous pouvons tous apprendre de quelqu’un d’autre, toutes les modifications sont examinées par un autre développeur. Cela peut être n’importe qui. Le point importante dans tout cela, comme c’est également le cas pour la programmation en binôme, est d’avoir une autre paire d’yeux sur le problème, même si nous demandons parfois à une personne en particulier disposant d’une expérience spécifique au problème d’effectuer la critique de notre code.

Après quelques petits allers-retours, l’examinateur peut finalement décider d’inclure la fonctionnalité dans le code de base. Il est de plus conforté dans sa décision par Semaphore, qui a pu également tester la branche et rendre compte du résultat de la pull request.

code-review

Déploiement

Après la fusion, Semaphore va procéder aux tests de la nouvelle branche master. Ceux-ci doivent logiquement tous être corrects. Dans ce cas, il va automatiquement déployer le code sur la plateforme Heroku (ainsi que notifier HipChat). De plus, notre script de déploiement personnalisé utilise la librairie tracker-git, ce qui permet de mettre à jour automatiquement le statut des stories comme étant livrées.

Il est l’heure de commencer la story suivante !

HipChat integration

En espérant que cet article puisse aider les personnes à la recherche d’une manière efficace d’organiser leur travail !

Nous remercions l’équipe de Belighted pour ce partage. Si vous avez aimé cet article upportez leur projet ! Aimez leur page facebook, suivez-les sur twitter ou plus simplement, visitez leur site web.