La taille de l’équipe ou de l’application affecte-t-elle le processus de publication ? En fait ça dépend. Imaginons une startup avec une petite équipe. Dans ce cas, l’équipe crée généralement une fonctionnalité, puis la publie simplement. Imaginons maintenant un grand projet, par exemple une application bancaire, sur lequel de nombreuses équipes travaillent.

Dans ce cas, il devrait probablement y avoir un processus, des cycles de publication et peut-être une certaine bureaucratie. Sans cela, ce sera le chaos.

Alors, quand devient-il clair qu’il est temps de mettre en place un tel processus pour votre application ?

Dans cet article, je partagerai mon expérience de la mise en œuvre de Release Train pour l'application Dodo Pizza (Android et iOS) et les problèmes que nous avons rencontrés et qui ont poussé notre équipe à mettre en œuvre Release Train.

Si vous êtes le Team Lead/Tech Lead d'un projet Android ou iOS en pleine croissance et que vous n'avez pas encore géré le processus de release, j'espère que notre expérience vous aidera.

Comment c'était avant

En 2021, nous utilisions déjà une approche Trunk-based Development (TBD) dans nos équipes. Nous avons couvert le code avec des bascules de fonctionnalités, des tâches décomposées et effectué des tests unitaires et d'interface utilisateur. Nos branches de fonctionnalités n'ont pas duré longtemps et CI fonctionnait.

Le processus de publication était très simple : celui qui était prêt à déployer sa fonctionnalité la déployait.

Scénario idéal

Voici à peu près à quoi ressemblait le flux de travail de notre succursale. Plusieurs équipes (gris, bleu, orange et vert) ont travaillé sur différentes fonctionnalités. Puisque nous travaillions selon TBD, chaque fonctionnalité pouvait vivre via plusieurs branches consécutives.

Par exemple, l'équipe grise a réalisé sa fonction en 4 étapes, les équipes bleue et orange ont réalisé la leur en 1 étape et l'équipe verte a réalisé la leur en 2 étapes.

Lorsqu'une équipe terminait une fonctionnalité, elle pouvait déployer une version. Par exemple, si l’équipe bleue terminait une fonctionnalité, elle pourrait en faire une version. Ensuite, l'équipe orange terminait une fonctionnalité et réalisait une autre version.

Nous avions un flux parfait, comme il semblait alors. Cela a très bien fonctionné jusqu’à un certain point, mais toutes les bonnes choses ont une fin.

Quelque chose s'est mal passé : difficile, bondé et imprévisible

Mammouth

Le premier problème que nous avons rencontré était que les versions commençaient à accumuler beaucoup de fonctionnalités et devenaient trop volumineuses.

Les équipes n'ont pas toujours souhaité sortir leurs fonctionnalités tout de suite. Le processus de publication et de régression prenait du temps et prenait 3 à 4 jours. Ainsi, si votre fonctionnalité était petite et non urgente, vous ne pouviez pas toujours la publier vous-même, car probablement une autre équipe publierait bientôt une version et elle serait incluse dans cette version. En gros, ça ressemblait à ça :

C'était un arrangement assez fragile, surtout lorsque le nombre d'équipes commençait à croître. De nombreuses équipes ont développé de nombreuses petites fonctionnalités et le volume total de nouveau code dans chaque nouvelle version est devenu énorme. Quand quelqu'un devait sortir son gros long métrage, il devait sortir un mammouth entier avec.

Les lâchers de mammouths ont abouti à :

• régression retardée;

• risque plus élevé de bugs de régression ;

• risque plus élevé d’avoir un bug en production.

Nous devions faire en sorte que même si l'équipe bleue et orange de l'exemple ne voulait pas publier, la publication se ferait d'une manière ou d'une autre.

Goulots d'étranglement

Chaque équipe est unique et chaque fonctionnalité est différente. Parfois, les choses se passaient de telle manière que plusieurs équipes finissaient leurs longs métrages à peu près en même temps. Dans ce cas, il y a eu beaucoup de « attends-moi, je le fusionnerai demain matin, promis ! aller autour.

En fin de compte, ces goulots d’étranglement ont entraîné :

• des lâchers se transformant en mammouths ;

• les versions retardées affectent négativement les plans de l'équipe de publication, surtout si les besoins de tous les autres étaient satisfaits.

Nous devions apporter 2 changements cruciaux :

1. L’équipe de libération ne devrait avoir à attendre personne ;

   
   

2. toutes les autres équipes devraient savoir quand la prochaine version est attendue.

Manque de prévisibilité

Imaginez, l'équipe bleue a réalisé un petit reportage et s'attendait à ce que l'équipe orange le publie bientôt. Mais quelque chose s'est mal passé et l'équipe Orange n'a pas non plus déployé la version à cause de ses propres problèmes.

En conséquence, l’équipe bleue a informé l’entreprise que la fonctionnalité serait bientôt en production, mais cela s’est avéré trop tard. De ce fait, il est impossible de prédire quand le long métrage sera en production.

Cela ne veut pas dire que l'équipe bleue est irresponsable. S’ils ont une fonctionnalité très importante ou urgente, ils la publieront bien sûr eux-mêmes. Mais dans d’autres cas, il n’existe aucun moyen de savoir exactement quand la fonctionnalité sera disponible pour les utilisateurs.

Comme vous pouvez le deviner, nous rencontrons assez souvent de tels problèmes. Nous devions être en mesure de savoir exactement quand les clients mettraient une fonctionnalité en production, quelle que soit sa taille ou son urgence. Les trois problèmes (versions gigantesques, goulots d’étranglement et manque de prévisibilité) sont étroitement liés et se complètent.

Cependant, le manque de prévisibilité est probablement le plus fondamental et le plus important de tous. Cela génère d’autres problèmes.

Libérer le train

Nous en avons assez ; il était temps de faire un changement. Le Release Train était censé nous aider à y parvenir.

Le terme Release Train signifie différentes choses : un processus de publication planifié ou une équipe dédiée qui gère le processus de publication. Ici, nous allons parler du processus de sortie planifiée.

J'aime la façon dont Release Train est décrit par Martin Fowler dans l'article « Modèles de gestion des branches de code source », et la définition donnée par Thoughtworks dans leur radar technologique (peut-être qu'elle appartient aussi à Martin).

C’est ainsi que nous avons défini Release Train pour nous-mêmes :

Release Train est le processus de coordination des versions entre les équipes. Toutes les versions ont lieu selon un calendrier fixe, que les fonctionnalités soient prêtes ou non. Le train n'attend personne. Si vous êtes en retard, vous devez attendre le suivant.

Décomposons-le avec quelques exemples utilisant nos équipes codées par couleur.

Résoudre le problème du mammouth

Release Train se déroule dans les délais et ne dépend pas de qui a fusionné quoi dans la branche principale. Dans l'exemple ci-dessous, les fonctionnalités des équipes bleue et orange seront publiées. Le reste attendra le prochain train. Nous pourrions attendre encore un peu, mais nous aurions alors un mammouth.

Résoudre les goulots d'étranglement

Dans le même temps, le Release Train nous aide à planifier notre travail plus efficacement. Disons que l'équipe bleue avait initialement prévu de terminer une fonctionnalité plus tard. Mais comme tout le monde connaît la date de sortie, ils peuvent légèrement réorganiser leurs plans pour terminer la fonctionnalité plus tôt.

Ou, au contraire, ils peuvent se rendre compte qu'ils ne seront certainement pas à l'heure pour le prochain train et ainsi terminer le long métrage en toute sécurité car ils connaissent tout l'horaire.

Dans l'exemple ci-dessous, l'équipe bleue souhaitait accéder à la version et fusionner toutes ses modifications avant la sortie. Sinon, il y aurait peut-être eu un goulot d'étranglement.

Plus important encore, Release Train nous a offert une prévisibilité dès la conception .

Ces exemples peuvent paraître évidents à certains, mais nous avons résolu les problèmes au fur et à mesure qu’ils se présentaient. Lorsqu'il n'y avait aucun problème avec les versions, nous ne prenions pas la peine d'utiliser Release Train. Lorsque les problèmes se sont accumulés, nous avons réalisé que le moment était venu.

Comment mettre en œuvre le Release Train dans votre équipe

La première chose que nous avons faite a été d'écrire une RFC . Une RFC fait référence à la fois au processus lui-même et au document de conception que de nombreuses entreprises utilisent avant de commencer à travailler sur un projet. Certains utilisent spécifiquement les RFC, d'autres utilisent les ADR et certains les appellent simplement par le terme plus générique Design Doc.

Chez Dodo Engineering, nous utilisons à la fois les RFC et les ADR.

Notre processus RFC ressemblait à ceci :

1. Nous avons rédigé un document RFC ;

   
   

2. nous en avons discuté en petit groupe, recueilli des commentaires et procédé à des ajustements ;

   
   

3. puis la RFC a été communiquée à un groupe plus large ;

   
   

4. puis nous l'avons mis en œuvre ;

   
   

5. après cela, nous avons recueilli des commentaires, suivi des mesures et évalué les résultats.

La structure du document RFC pour notre Release Train était la suivante :

• description du processus Release Train ;

• quelles équipes sont impliquées, ce qu'elles font ;

• quel sera le calendrier ;

• métrique.

Lors de la rédaction du RFC, nous nous sommes appuyés sur l’expérience d’autres sociétés :

• SkyScanner
• Nuage sonore
• Monzo
• Facebook

Première mise en œuvre

Tout d’abord, nous avons proposé ce processus :

• sortie chaque semaine ;

• créer une branche de release mercredi matin ;

• terminer la régression et envoyer l'application pour examen vendredi ;

• commencez à déployer la version lundi.

• Équipe de publication :

  • 1 développeur iOS et 1 développeur Android d'une des équipes fonctionnelles ;

  • 2 ingénieurs QA.

    
    

• créer une nouvelle branche de publication mercredi ;

• établissez un calendrier un trimestre à l'avance, en indiquant quand c'est au tour de chaque équipe de sortir. Après un trimestre, réunissez-vous et prolongez le programme.

Schématiquement, notre Release Train ressemblait à ceci :

Tout ne s'est pas bien passé

Au bout d'un mois, il est devenu clair que même si la première expérience avait été formidable,

• C'était vraiment difficile de faire une régression chaque semaine et d'avoir terminé le vendredi ;

• il n'y avait pas de temps pour les correctifs, et ils arrivaient parfois.

En 2021, notre test de régression prenait en moyenne 3 à 4 jours. Nous avons réussi à le raccourcir à 2 ou 3 jours en 2022, mais parfois, cela dépassait ce délai. Nous avons continué à couvrir les cas de régression avec les tests e2e, mais nous n'avions pas encore une couverture à 100 %. Nous avions respectivement une couverture d’environ 70 % et 60 % des cas de régression sur chaque plateforme.

Ce qu’il faut retenir, c’est que tant que les tests de régression prennent quelques jours, il sera probablement inconfortable d’exécuter un cycle de publication chaque semaine.

La réponse finale

Nous avons fini par passer à des cycles de publication de 2 semaines, et Release Train ressemble maintenant à ceci :

• sortie toutes les 2 semaines ;
• créer une branche de release mercredi matin ;
• régresser et envoyer l'application pour examen vendredi ;
• commencez à déployer la version lundi.

• Équipe de publication :

  • 1 développeur iOS et 1 développeur Android d'une des équipes fonctionnelles ;

  • 2 ingénieurs QA.

    
    

• établissez un calendrier un trimestre à l'avance, en indiquant quand c'est au tour de chaque équipe de sortir. Au bout d'un trimestre, réunissez-vous et prolongez l'horaire.
• déployer la version progressivement ;
• faire les correctifs si nécessaire, maintenant que nous en avons le temps ;
• une semaine plus tard mercredi, créez une nouvelle branche de publication.

Voici à quoi ressemble le processus si tout se passe comme prévu :

Tout cela ressemble à un cycle hebdomadaire, sauf qu'il reste suffisamment de temps pour d'éventuels correctifs. Voici à quoi cela ressemblera en cas de tests de régression étendus :

Ce n’est pas grave non plus ; il est encore temps même pour les correctifs.

Comment le nouveau processus a-t-il affecté la prévisibilité ?

Notre objectif principal était d'accroître la prévisibilité . Il peut être décomposé en deux parties :

1. Quand la demande sera-t-elle publiée ?
2. Dans quelle version ma fonctionnalité sera-t-elle disponible ?

Nous avons répondu à la question « Quand y aura-t-il une sortie ? » en mettant en œuvre le processus Release Train. Désormais, chaque équipe pourra répondre à la question « dans quelle version aboutira ma fonctionnalité ? de manière indépendante au moment où ils planifient et évaluent la fonctionnalité.

Avant, il était impossible de le dire avec certitude car une autre équipe pouvait ou non réaliser la sortie. Désormais, tout dépend uniquement de la propre planification de cette équipe.

Pour confirmer davantage cela, nous avons mené des enquêtes auprès des développeurs mobiles, de l'assurance qualité et des chefs de produit, où, ensemble, avec d'autres questions, nous avons posé :

• A quand la prochaine sortie ? (100% ont répondu à cette question).

• Release Train vous a-t-il aidé à planifier votre travail d’équipe ? (75% ont répondu positivement, mais certains ont parfaitement prédit leur travail même sans Release Train).

Release Train nous a également aidé avec les gels de code et les gels de versions. Nous en avons eu plusieurs, en plus du réveillon du Nouvel An (par exemple le 1er septembre et certains jours fériés). Désormais, avec Release Train, nous n'avons plus besoin de nous adapter à ces dates en créant des branches de publication, des tests de régression, etc. Libère le travail dans les délais prévus ; nous les ouvrons simplement dans les magasins plus tard.

Impact sur les métriques

Au-delà de la simple résolution de problèmes, nous avons également mesuré des indicateurs. Jetons un coup d'œil aux principaux.

Délai de mise en œuvre

La première mesure importante que nous avons mesurée était l' engagement dans le délai de livraison .

Voici à quoi ressemble le graphique. J'ai marqué le moment où nous avons démarré le processus Release Train avec une flèche.

Le graphique montre que le délai de livraison a été réduit à environ six jours. Est-ce que six jours, c’est long ou court ?

Références Google

Il y a benchmarks de Google pour cette métrique , mais c'est surtout pour le backend. A leur échelle, ils distinguent les groupes suivants :

• Élite : moins d'une heure
• Haute : 1 heure à 1 semaine
• Moyen : 1 semaine à 6 mois
• Faible : 6 mois ou plus

Je pense que pour les applications mobiles standards, le délai de livraison devrait idéalement viser la moitié de la durée du cycle de publication. Cela équivaut à fusionner chaque jour une tâche dans la branche principale. Ceci dit, si le cycle de release est de 14 jours, le Lead Time devrait viser 7 jours .

Bogues par régression

Une autre mesure que nous suivons est le nombre de bugs par régression. Il décrit la stabilité de la version candidate. Si la version précédente date d'il y a longtemps, nous avons probablement créé beaucoup de nouveau code susceptible de contenir un grand nombre de bogues, et nous pourrions consacrer plus de temps à la régression et aux correctifs.

À un moment donné, cette métrique comportait trois bugs. Les chiffres précis ne sont pas si cruciaux, mais dans l’ensemble, vous pouvez constater que la tendance est à la baisse.

Plus de mesures

Je discuterai brièvement des mesures qui ont également été surveillées dans le cadre du Release Train.

• Sans crash. Nous gardons toujours un œil sur cette métrique. Il y avait une hypothèse selon laquelle il diminuerait en raison de nos tentatives pour adapter la régression à un calendrier plus serré. Eh bien, aucune chute ne s'est produite.

• Nous nous sommes demandés si des versions fréquentes (hebdomadaires) auraient un impact sur le taux de désabonnement des clients et sur la suppression de l'application. En conséquence, nous n’avons détecté aucun impact.

Mettre en œuvre, améliorer

Nous apprécions le processus actuel car nous pensons qu’il a atteint ses objectifs. Nous savons également comment l’améliorer encore :

• Nous continuons à travailler sur l'automatisation de la régression pour la rendre plus simple et plus rapide.

• Jusqu'à présent, nous avons laissé de côté la partie sur l'automatisation du travail (scripts pour le branchement), mais cela constituerait également un grand point de croissance dans le futur.

• Notre application fonctionne dans 20 pays et nous devons la traduire dans de nombreuses langues différentes. Il existe un service interne pour cela, mais les développeurs doivent toujours participer manuellement à ce processus avant la sortie. L'automatisation de ce processus pourrait potentiellement améliorer encore davantage le cycle de publication.

Résumé

Même si nous étions relativement petits, nous n'avions pas besoin d'un Release Train. Lorsque nous avons été confrontés au fait que nous ne pouvions pas prédire les versions, leur taille et leur nombre, nous avons décidé de mettre en œuvre Release Train. Au début, nous avons essayé des cycles de publication hebdomadaires, mais en raison de régressions chronophages, nous avons dû passer à des cycles de publication de deux semaines. Depuis, nous vivons ainsi.

Désormais, nous disposons d’une prévisibilité des versions et les mesures montrent une dynamique positive. Nous prévoyons d'augmenter la couverture des cas de régression avec les tests e2e, d'automatiser le processus de travail avec les succursales et d'optimiser le processus de traduction.

J'espère que cet article et notre expérience vous aideront, surtout si vous avez déjà rencontré des problèmes similaires et qu'ils vous ont fait réfléchir au processus de publication.

Merci beaucoup d'avoir lu mon article. J'espère que tu as aimé. Si vous avez des questions ou des suggestions, écrivez-moi dans les commentaires et je ne manquerai pas de la lire !

Et Suis moi sur Twitter . Habituellement, je publie sur le développement Android et le génie logiciel en général.

Également publié ici