Comme promis, nous continuons d’avancer en cette période de transition. Qui dit avancer, dit avancées technologiques, et qui dit avancées technologiques, dit procédures de déploiement, aussi appelées “release process” dans le jargon. 

Cette introduction vous semble tirée par les cheveux ? Rassurez-vous, le reste de l’article sera on ne peut plus sérieux ! Nous avons aujourd’hui l’honneur d’accueillir Arnaud Sourioux aka Six. (parce qu’il a six ans d’âge mental ? Ou six doigts ? Le mystère reste intact…). Directeur Technique Adjoint, il connaît toutes les ficelles pour mener à bien les procédures de mise en production. 

Et oui, lorsqu’une nouvelle mise à jour ou qu’un correctif de bug apparaissent sur votre Shadow, il y a d’abord tout un processus à gérer et à mettre en place. À savoir que typiquement, nos mises à jour passent par des phases d’“Insider”, d’”Alpha”, puis de “Beta” avant de passer en version “Officielle” et d’être visibles par tout le monde. Maintenant que vous connaissez le B à B-A (Beta-Alpha ?), place à notre session de questions-réponses, où nous entrerons plus en détails sur ces différentes versions et vous donnerons bien plus d’explications sur tout le reste de la procédure : 

Q : Comment s’articule la sortie d’une mise à jour de Shadow ? Est-ce que ça a toujours été comme ça ?

Non, ça n’a pas toujours été comme ça. On change la façon de faire les choses. Il y a 2 ans, lorsque je suis arrivé chez Shadow, on sortait les mises à jour à peu près… dès que c’était prêt ! Ensuite, on a essayé de synchroniser les versions entre l’application, le client, ce que voit l’utilisateur et les services dans Shadow. On a beaucoup industrialisé et on a utilisé des outils pour nous aider à faire ça, tels que Gitlab pour n’en citer qu’un. 

Arrive l’ère JB où il a décidé de ne faire qu’une sortie en production par mois, pour qu’on puisse chaque semaine se focaliser sur une partie de Shadow. Par exemple, la semaine 2 de chaque mois est dédiée à la partie “application client”, c’est-à-dire la version desktop (bureau), box (boîtiers), mobile, TV. La semaine 3, elle, se focalise sur les composants dans Shadow : l’encodeur (ou streamer) et tous les services qui permettent à Shadow de fonctionner. 

Pour ce qui est de la sortie d’une mise à jour : la première chose à faire est de définir ce que l’on va mettre dans la première version, c’est-à-dire les features (fonctionnalités). Les bug fix (correction de problèmes), on les fait au fur et à mesure donc tous ceux qui ont été effectués jusque là seront inclus avec cette version. On définit nos contenus en avance pour être sûrs de les inclure dedans. 

Q : À quoi servent les versions Insider, Alpha et Beta ? 

En phase de test, on commence toujours par envoyer notre mise à jour en Insider. L’intérêt c’est qu’on peut leur envoyer directement le code qu’un développeur vient de faire, on a pas besoin de faire une “vraie version” pour eux. Grâce à ça, ils peuvent accéder à une version à peine 20 minutes après qu’un développeur l’ait écrite. 

L’Alpha, elle, est un code figé (non de test), mais on peut en envoyer 3 par jour.

Pour une vraie version Beta, on est obligés de passer par une phase QA. La QA doit tout tester et nous dire si ça fonctionne, si c’est pour la Beta, ou si ce n’est pas assez acceptable en fonction des bugs trouvés. 

Pour passer de la Beta à la version Officielle, c’est la Beta en cours qui est re-testée de manière plus approfondie. On est beaucoup plus stricts sur tous les comportements et bugs trouvés pendant les phases de tests. 

Ces versions nous servent à garantir que petit à petit, en montant de Insider, à Alpha, à Beta et à la version Officielle, on s’assure d’un gage de qualité. Comme on a pas le même volume d'utilisateurs, l’impact n’est pas le même. Quand on envoie une mise à jour ou un correctif en Beta c’est seulement 10% des utilisateurs qui sont impactés, et ils peuvent choisir de passer en Alpha ou en version Officielle en cas de besoin. 

Q : Comment est-ce qu’une nouvelle feature passe de la version Insider à la version officielle (les étapes concrètes) ?

À chaque fois qu’une nouvelle feature (fonctionnalité) passe à la version supérieure, ses finitions et l’expérience utilisateur doivent être augmentées. Les exigences ne sont pas les mêmes en Alpha qu’en Beta ou qu’en version Officielle. 

Par exemple, en Alpha aujourd’hui nous avons l’application arm64 pour Mac. Elle est en Alpha parce qu’il n’y a pas encore toutes les fonctionnalités telles que le Menu Rapide, le Display Management ou d’autres qui fonctionnent avec. Elle a pu passer très rapidement en Alpha car elle ne gêne pas mais pour la Beta elle nécessite un minimum de fonctionnalités. Et pour la version Officielle, c’est encore une autre histoire. 

Q : Y’a-t-il une date/jour à laquelle vous sortez les release ? Genre vendredi soir parce que c’est Shadow ?

Il y a l’histoire des semaines de release en fonction du composant qu’on va mettre à jour dont on parlait plus tôt. Plus le scope est haut (version Officielle > Beta > Alpha), plus ce sera en début de semaine. 

Pour la version Officielle, on essaye de faire ça le lundi ou le mardi. Pour la Beta, on s’autorise jusqu’à jeudi. Et pour l’Alpha, on fait ça quand on veut. Même si on a des retours très rapides, il nous faut tout de même du temps pour corriger avant le weekend qui arrive car c’est là qu’on a le plus d’utilisateurs connectés, d’où nos contraintes au niveau des jours de la semaine. Quand on sort la mise à jour le lundi ou le mardi, ça nous permet d’apporter des correctifs avant le vendredi, ce qui permet à nos utilisateurs d’avoir une version Beta ou en version Officielle relativement stable ou exempte des bugs trouvés entre temps. 

Q : Quelle est la plus grande difficulté à laquelle doit faire face l’équipe pour lancer une nouvelle mise à jour ?

Plus il y aura d’équipes chez nous qui seront concernées sur le développement d’une feature, plus ça va être difficile. Plus il y a d'équipes concernées, plus nous allons devoir travailler ensemble et nous synchroniser, plus ça va être compliqué : il faut se mettre d’accord sur comment la faire. 

Aujourd’hui, il y a beaucoup de features qui paraissent simples mais qui ne le sont pas tant que ça. Quand on a une feature sur le Menu Rapide, il faut que lorsque l’utilisateur clique sur le Menu Rapide, que cela soit envoyé dans le Shadow par l'application locale. Par exemple, lorsqu’on change de résolution sur le Menu Rapide, ça envoie l’information au moteur de rendu qui la transfère à l’encodeur. L’encodeur applique la nouvelle résolution et confirme au moteur de rendu ainsi qu'au Menu Rapide que c'est bien appliqué.Tout cet enchaînement qui paraît très simple en tant qu’utilisateur n’est au final pas si simple que ça.

En plus quand on rajoute la partie virtualisation / orchestration - Par exemple la sur le dynamic shutdown (extinction dynamique) ça prend encore plus de temps car il faut que tous les composants arrivent à se parler entre eux pour que ça se passe bien. 

Q : Pourquoi c’est aussi compliqué ?

Ce qui est compliqué c’est qu’en fait on part d’une spécification produit qui est un besoin pour le client, qu’on doit le retranscrire techniquement et s’assurer qu’on sait tout faire. Parfois, on ne sait pas comment faire et on doit chercher comment faire. Combien de temps ça va prendre. Et s’assurer avec tout le monde qu’on peut faire d’une certaine manière.. Le but c’est de ne pas empiler des trucs qui marchottent tout seuls mais pas avec le reste ou pas avec la prochaine feature. Le but c’est de trouver des solutions pérennes. 

Pourquoi il y a toutes ces étapes et pourquoi ça peut prendre du temps ? Pour que la qualité soit un maximum au rendez-vous car les utilisateurs sont de plus en plus exigeants. Au début quand le produit s’est lancé, nos membres savaient qu’ils testaient un truc qui démarrait, ambiance j’ai fait mon produit dans mon garage. Maintenant, tu achètes Shadow comme tu achètes un abonnement à n’importe quoi d’autre donc tu t’attends à une qualité similaire. 

Avant, on avait que les versions Insider / Beta / Officielle et on s’est dit qu’il nous fallait la version Alpha. On nous demandait la même qualité en Beta qu’en version Officielle, ce qui n’était pas possible sans étape intermédiaire. 15 insiders ça ne permet pas de toucher 10% des utilisateurs en Beta juste après de manière correcte. Même là quand on a des bugs en version Officielle, c’est qu’on a envoyé en Beta et qu’on a pas eu de retours (car une ou 2 personnes ont du l’avoir en Beta) et quand on passe en version Officielle l’impact n’est pas le même : les 2 personnes peuvent se transformer en en 100, 200, 500 ou 2000 personnes le premier soir. Les conséquences peuvent être dramatiques. 

Le pire qui puisse nous arriver sur un bug qu’on met en version Officielle c’est que l’utilisateur n’ait plus accès à Shadow. C’est pour ça qu’on essaye de faire le plus attention possible sur les phases d’avant. 

Quand on met une mise à jour en Beta ou en version Officielle, c’est en fonction du nombre d’utilisateurs impactés qu’on décide de la marche à suivre. En fonction du bug, on l’étudie, on trouve une solution, on vérifie qu’on arrive à le résoudre avant d’envoyer un correctif à tous ceux qui sont impactés (et pas juste pour la personne en question). Si on revient à la version précédente, il n’y plus le bug mais ça veut dire qu’on est quand même bloqués quelque part. 

Q : Est-ce que tu mérites une augmentation ? Et le mot de la fin ! 

Ce sont les équipes qui en méritent le plus. C’est eux qui font le boulot, nous on organise tout ce qu’il y a autour. 

Je pense qu’on a vraiment fait de gros progrès en 2 ans. Parce que l’équipe est plus importante, parce qu’on a fait les choses différemment, parce qu’on a de nouvelles têtes. Par moments on va être moins agiles et moins rapides mais on a gagné en qualité. C’est pour ça qu’on a voulu remontrer qu’on était agiles et capables de faire de belles choses en sortant le double écran sur la Box V1 pour Noël (disponible en Beta). Ça tenait autant aux utilisateurs qu’à une partie de l’équipe !