#5 Journal d’un développeur chez Esker : Procédure de Tip Toe et Repositories
Cela fait plus de deux ans que j’ai décroché mon premier emploi chez Esker. Je suis développeur dans l’une des dix équipes de la R&D en charge du développement des solutions à destination de nos clients. Nous sommes entre quatre et six développeuses/développeurs par équipe, et travaillons tous en méthode Agile sur une base de code commune afin de développer de nouvelles fonctionnalités pour nos produits. Mais notre travail ne se limite pas à ça ! Je tenterai donc de t’en présenter toutes les facettes en plusieurs articles. Tu peux retrouver les sujets précédents sur la page d’Esker Labs.
Cette fois-ci, ça y est : j’ai terminé mon développement, j’ai fait des tests manuels et automatiques sur la story, et elle est prête à partir en production. Prête ? Pas exactement, il reste encore quelques étapes avant que nos clients aient la joie d’utiliser la nouvelle fonctionnalité que j’ai développée !
Étant environ 100 développeuses et développeurs à travailler en méthode Scrum sur la même base de code dans le département R&D, tu te doutes bien qu’il a fallu s’organiser pour gérer les différents développements de chaque équipe. Pour cela, nous utilisons un outil de gestion de versions, avec un répertoire (ou repository) dans lequel toutes les équipes poussent leurs modifications du code de notre produit. Ce répertoire est organisé en différentes branches, qui sont en fait des lignes de développement parallèles. Quatre branches principales ont été créées :
- Production est la branche dans laquelle on retrouve le code source actuellement en production ;
- Deploy est la branche contenant le code source qui va être déployé prochainement en production. Elle est notamment utilisée par l’équipe en charge des installations ;
- Integration est une branche contenant une version relativement stable du code source et représente une sorte de sas de stabilisation entre la branche default et la branche deploy ;
- Default est la branche contenant tous les derniers développements des équipes R&D.
Chaque développement suit donc les étapes suivantes afin d’être intégré au produit :
1/ DÉVELOPPEMENT DE LA STORY
Lorsque j’ai commencé à développer ma story (enfin, la mienne et celle de mon équipe bien sûr!), j’ai créé une branche spécifique dans laquelle j’ai poussé toutes mes modifications. Utiliser une branche différente de la branche commune me permet à la fois de ne pas pousser de code instable sur une branche utilisée par d’autres équipes, mais aussi de mieux identifier la cause des éventuels bugs que je pourrais rencontrer : si je trouve un bug sur la branche default, il ne provient pas des développements mis en place dans le cadre de ma story, alors que si j’en trouve un sur ma branche de story, il provient probablement de mon développement en cours.
2/ INTÉGRATION AU CODE COMMUN
Lorsque j’estime que mon développement est suffisamment stable pour être intégré au produit, je fusionne (ou merge) ma branche de story avec la branche default. C’est cette version du produit qui est testée chaque nuit par la batterie de tests automatiques de chaque équipe. Ces résultats de tests étant analysés chaque jour, nous pourrons donc détecter si j’ai accidentellement provoqué une régression avant que celle-ci soit déployée en production.
3/ DÉMARRAGE DU MODE TIP TOE
Un jeudi sur deux, l’ensemble de la R&D entre dans ce qu’on appelle le mode Tip Toe. Tu te demandes sûrement ce qui se cache derrière ce nom barbare ? C’est assez simple en fait : en méthode Scrum, un incrément de produit doit être déployé de manière régulière. Chez Esker, nous avons choisi une fenêtre de développement de deux semaines. Mais pour respecter ce délai, il nous faut définir un moment à partir duquel nous ne pouvons plus intégrer de nouveaux développements à la version qui va être déployée. C’est exactement ce à quoi sert le mode Tip Toe : dès que celui-ci a démarré, la branche default est fusionnée avec la branche integration. Tous les développements qui sont fusionnés dans cette branche seront intégrés à la prochaine version du produit. Lorsque ce mode a commencé, il n’est plus possible de pousser de nouvelles features dans la prochaine version du produit, mais il est toujours possible de fixer les bugs restants afin d’obtenir la version la plus stable possible du produit.
4/ STABILISATION DE LA VERSION COURANTE
Mes développements ont donc maintenant été inclus dans la branche integration suite au passage en mode Tip Toe. Chaque jour, les équipes de la R&D se réunissent lors de la “réunion Go/No Go” afin de décider si la version du produit actuellement sur la branche integration est assez stable pour être déployée et utilisée par les clients. Si toutes les équipes ne sont pas “Go”, cela signifie que cette version n’a pas encore le niveau de qualité requis pour être déployée en production ! Le mode Tip Toe a donc une durée variable (entre 3 et 5 jours en général).
5/FIN DU MODE TIP TOE ET DÉMARRAGE D’UN NOUVEAU SPRINT
Ça y est, toutes les équipes sont “Go”, une nouvelle version du produit est prête à être installée, et elle contient nos nouveaux développements ! La branche integration est fusionnée avec la branche deploy. La R&D sort du mode Tip Toe, et le prochain sprint, sur lequel nous avions déjà commencé à travailler, devient le nouveau sprint de référence !
Quelques jours plus tard, l’équipe en charge des installations utilise la branche deploy pour déployer le nouvel incrément sur notre plateforme. La branche deploy est finalement fusionnée avec la branche production. Tous nos clients peuvent à présent utiliser la nouvelle fonctionnalité que j’ai aidé à développer :)
Tu as hâte de savoir la suite ? C’est par ici :
Retrouve les autres parties du journal d’un développeur chez Esker :
