De l’importance des process • wi-run, the code

Au long de ma carrière, j’ai eu l’occasion de connaître des modes de travail différents. Des équipes auto-gérées et des équipes procédurières, avec ou sans lead, avec ou sans process.

TL;DR

La constance des équipes qui fonctionnent se trouve souvent dans les process mis en place. Il n’y a pas de recette miracle, chaque équipe est différente et doit faire ses propres ajustements. Reprendre ce qui marche pour une autre équipe n’est pas l’assurance du succès mais seulement un point de départ. Ce que j’ai pu constater, c’est que toutes les équipes qui fonctionnent ont su mettre en place des process de travail adaptés.

L’outillage et la documentation sont des aspects indispensables lors de la mise en place de process, ils ne doivent pas être éludés pour des questions de temps. Un process n’existe que s’il est écrit et l’écriture d’un process doit se faire en équipe.

En l’absence de process

Le plus souvent, les équipes réduites ou naissantes ne voient pas la nécessité de se contraindre à la mise en place de process dont elles n’ont pas l’utilité, et c’est souvent vrai au tout début. Mais très vite, dès que l’équipe va s’étoffer, on va voir arriver les premiers signes de nécessité : des nouveaux qui ont du mal à trouver leur place, qui sont dépassés par la masse de choses qu’on leur explique en vrac, des anciens très occupés, qui n’ont pas le temps d’expliquer comment on fait des mises en prod ou comment on release le code, …

Le résultat c’est une incorporation des nouveaux arrivants longue et difficile, c’est aussi des anciens qui gardent des rôles clés et qui ont du mal à partir en vacances. Et c’est surtout des frustrations dans l’équipe entre les nouveaux qui ne comprennent pas ce que l’on attend d’eux et les anciens qui ne comprennent pas pourquoi les nouveaux mettent autant de temps à rentrer dans les sujets.

Quelques exemples de process

Voilà quelques exemples de process qui fonctionnent pour nous chez i-Run.

La revue de code

On ne débattra pas ici de l’utilité ou non de la revue, c’est un sujet bien différent. Pour les équipes qui choisissent de mettre en place des revues de code, il est important de préciser le process sous peine de voir cette étape devenir une source de frustration, pour les développeurs comme pour la direction, qui y voient une perte de temps. Instaurer un process clair permet d’éviter ces frustrations.

Plusieurs éléments doivent être déterminés :

Quel code est à revoir ?
Qui revoit le code ?
Combien de personnes doivent relire le code ?
Quand revoit-on le code ?
Qui est responsable de faire passer sa revue ?

Dans l’équipe SI d’i-Run, tout code est systématiquement revu. La revue se fait en deux temps, la relecture et la validation. Durant la relecture, la merge request est en WIP, tous les développeurs sont invités à relire le code et faire des remarques. L’objectif ici étant de partager la connaissance du code. Quand un relecteur n’a plus de remarque, il met un “👍” sur la merge request. Le 2ième développeur qui met un “👍” enlève le WIP. La merge request passe alors en phase de validation, le responsable de code, un développeur plus à l’aise que les autres sur le sujet traité, approuve la merge request. La branche passe alors en Attente de MEP. Chaque développeur est responsable de ses merges requests et de leurs avancées dans le process, c’est lui qui relance l’équipe quand une MR traîne. Les développeurs font les relectures en continu, entre deux développements ou en début ou fin de journée. L’important est que le processus reste fluide.

Déploiement Production

Autre exemple de process important et qui évite les sueurs froides, la Mise en Production. Une fois notre branche validée et en attente de déploiement, qui se charge de valider les fonctionnalités ? Comment valide-t-on ? Qui release le code ? Comment ? Qui déploie sur les serveurs ?

Dans le cas d’i-Run, nous avons besoin de beaucoup de souplesse lors de nos déploiements fréquents (1 à 3x par semaine). Nous avons donc mis en place un processus adapté.

Le responsable fonctionnel crée une “milestone” qui regroupe les tickets/fonctionnalités qu’il souhaite mettre en production. À partir de ces tickets et des branches associées, on merge une branche de staging qui est déployée, toujours par le responsable fonctionnel, sur un environnement de staging. L’équipe fonctionnelle fait alors une première validation des fonctionnalités et si besoin fait des retours aux développeurs. Le cycle revue -> merge -> déploiement de staging se poursuit jusqu’à ce que la validation soit terminée.

La souplesse ici est de pouvoir retirer une fonctionnalité de la milestone si elle s’avère plus compliquée que prévu, et ainsi ne pas pénaliser les autres tickets qui pourraient être plus urgents. D’autre part, on est capable de compiler et de déployer plusieurs environnements de staging en parallèle pour que la validation d’une milestone plus conséquente ne ralentisse pas les milestones plus urgentes.

Quand la milestone est validée sur staging, l’équipe fonctionnelle débute une release des applications qui va fixer les versions. Une fois la release terminée, les versions obtenues sont déployées sur l’environnement de pré-production où elles sont vérifiées une dernière fois dans des conditions très similaires à celles de la production.

Une fois la pré-production validée, le responsable fonctionnel va lancer le déploiement de la version sur les machines de production.

Ce processus de validation/déploiement nous a permis, depuis qu’il est en place, de réduire les incidents de production à moins d’une dizaine par an. Mais il a été long à mettre en place et a demandé bon nombre d’ajustements avant d’être efficace. Les premiers temps, il a surtout allongé les délais de déploiement, mais rapidement, la confiance qu’il a amenée a permis d’augmenter les cadences de livraison.

L’application des process

On le voit avec l’exemple précédent, parfois les process sont complexes et amènent des lenteurs, d’où leur rejet par les développeurs comme par la direction. C’est pourquoi, avant même de penser un process il faut penser sa mise en application. Elle va principalement se faire autour de deux axes.

Outillage

Les process acceptés sont ceux qui profitent à toute l’équipe et pas seulement à une partie. Si un process assure la non-régression mais qu’il donne deux fois plus de travail aux développeurs, il ne passera pas. Idem si un process fait gagner du temps aux développeurs mais que la validation prend deux fois plus de temps à l’équipe fonctionnelle, le process ne sera pas suivi. Il ne faut pas sous-estimer les outils. Souvent coûteux à développer, ils n’amènent pas de valeur aux applications et n’apportent donc pas de retour sur investissement direct. Ils sont pourtant la condition principale pour la mise en place de process automatisés.

L’outillage va permettre de fluidifier les process et de déplacer leur complexité vers le développement des outils plutôt que dans leur mise en application.
Si on prend l’exemple de notre process de déploiement, c’est un outil simple d’utilisation qui permet à l’équipe fonctionnelle de compiler des milestones et de déployer des environnements jusqu’à la production. L’outil a pris plusieurs mois de développement et encore plusieurs mois de tests et d’ajustements. Mais aujourd’hui, n’importe qui, avec les autorisations nécessaires, est capable de déployer des environnements sans qu’un développeur ne soit obligé d’intervenir.

Ce niveau d’automatisation n’est pas gratuit : nos tickets, nos merges requests, nos noms de branches sont strictement normalisés et les manquements à ces normes sont signalés durant les revues. Ce qui demande à l’équipe de développement comme à l’équipe fonctionnelle d’être plus vigilants. D’un autre côté, les développeurs apprécient de ne pas avoir à s’interrompre pour faire une release ou un déploiement, les consultants fonctionnels sont satisfaits de pouvoir organiser les mises en production sans avoir à dépendre des développeurs ou des administrateurs. Bref, tout le monde y gagne.

Et mêmes les quelques contraintes de normalisation sont facilitées par des outils. Par exemple, un outil permet aux développeurs de créer des merges requests automatiquement depuis leur branche de développement. Garantissant que la MR respecte la norme.

Documentation

Un process qui n’est pas posé par écrit n’existe pas. Sans un texte clair, il est impossible d’être certain que tout le monde ait bien compris le process de la même façon. De même, lors de l’arrivée de nouveaux membres dans l’équipe, il sera plus efficace de donner la documentation à lire plutôt que de prendre du temps à expliquer un process avec le risque de déformation à l’oral.

Les process, pour être acceptés, doivent être validés en équipe. L’écriture d’une documentation pérenne permettra cette validation, l’entérinera et rendra le process officiel. À partir de là, il sera possible de faire remarquer les manquements au process puisqu’ils ne souffriront plus de l’appréciation ou de la compréhension de chacun et qu’ils auront été acceptés par toute l’équipe.

Conclusion

Les procédures et les process de travail sont parfois mal considérés ou pris comme une perte de vélocité ou de flexibilité. Mais des process adaptés et éprouvés vont au contraire éviter d’avoir a se reposer éternellement les mêmes questions et problématiques lors du cycle de développement. Pensez et mettez en place vos propres process, progressivement en prenant soin de cibler votre besoin précisément, vous y gagnerez en efficacité.

Et surtout restez #Runstoppable