La nouvelle version de Skello, que nous avons été ravis de partager avec vous et nos clients fin mars, est issue d’un projet ayant débuté en été 2019 ! Si elle n’est pas une réécriture totale de notre solution, elle a fait l’objet d’une refonte globale de l’interface utilisateur. Notre Full Stack Developer, Camille, explique les différents process mis en place durant le projet et l’aspect progressif de la migration.
L’un des challenges que nous avions sur l’ancienne version de Skello, c’était son aspect très hétérogène. On avait un look & feel très différent selon les pages.
L’une des premières étapes pour régler ça a été de mettre en place un Design System global pour industrialiser tous nos blocs de design : on a défini en amont un système qui a homogénéisé les briques qui constituent aujourd’hui les pages de Skello. Découvrez comment ce Design System s'inscrit dans notre Brand refresh global. Tous les composants pratiques, les boutons, checkboxes, mais aussi la typographie, les couleurs des thèmes, les marges, l’espacement ont été pensés et définis en amont… Ce Design System a permis de tout rendre uniforme et de faire gagner du temps aux développeurs.
Avoir créé ça dès le début, ça nous a fait gagner du temps sur le long terme. Les composants étaient prêts à être utilisés lors de la réalisation des différentes pages tout en laissant une grande liberté graphique à notre équipe produit ! Les nouvelles pages Employés / Paramètres de l’établissement / Paramètres de l’Organisation ont pour le moment été mises en production à l’heure actuelle. Le projet de refonte globale va encore s’étaler sur les semaines et mois à venir.
En effet, nous avons revu toute la partie UI (User Interface — le design) & UX (User Experience — la navigation sur le site) de Skello le logiciel planning. La révision de toute la partie UX a amené un travail d’optimisation sur certaines parties du backend (partie invisible de la refonte) sans pour autant impliquer de changements de fonctionnement massifs !
Après avoir réalisé notre Design System, on a donc procédé à un découpage technique, en identifiant l’ordre des pages à changer puis on les a faites évoluer une à une ! Au sein même des pages, on a découpé le travail à effectuer en sections, pour pouvoir développer petit à petit. Les premiers bouts de code de cette nouvelle version ont été livrés en décembre 2019, ce qui veut dire qu’une partie du code des nouvelles pages était déjà présent sur les serveurs de production, bien que restant invisible aux clients à ce moment là. On parle de “Feature Flag” pour conditionner l’activation d’une fonctionnalité aux clients finaux : on minimise le risque en cas d’erreur ou de besoin de retour en arrière.
Ce qui a donc permis à cette migration de bien se passer, c’est son aspect progressif : la mise en production des changements a été faite de manière fréquente, ce qui était sécurisant pour les équipes produit et aussi bien sûr pour le client car moins déstabilisant ! Le fait de ne pas aller trop vite, de migrer page par page, a permis de réduire le champs des possibles en cas de problème ou de régression, en limitant la possibilité d’avoir des bugs.
Oui, on avait identifié en amont des développeurs responsables de certaines parties, certaines pages de l’application, en fonction de leur aisance et du travail de développement qu’ils avait réalisé auparavant ! Si jamais il y a un bug sur tel formulaire, on sait que ce sera telle personne qui sera “responsable technique” : c’est à dire que cette personne sera prête et identifiable par les autres membres de l’équipe pour être sollicitée en cas de bug urgent apparent !
On a beaucoup travaillé sur l’environnement de “staging” : cet environnement, que nous utilisons comme un environnement de pré-prod, c’est à dire sur lequel on teste nos nouvelles fonctionnalités avant qu’elles ne soient disponibles pour nos clients, contient toutes les fonctionnalités qui seront mises en production la semaine suivante. Les équipes ont donc pu tester les différentes nouvelles évolutions au fil du temps en simulant une utilisation de Skello “dans le futur”.
Au moment de l’activation, tout avait donc déjà été testé de manière progressive. Les dernières semaines, on a rejoué le scénario qui allait se produire fin mars pour s’assurer que l’opération se passe bien. Le but ? Être le plus proche de la réalité sans que ce soit la réalité.
Oui, on avait envisagé tous les scénarios possibles, malgré les nombreuses répétitions les jours précédents. Une mise en production contient toujours son lot d’imprévus, plus ou moins problématiques ou impactants. Il fallait qu’on soit donc prêts a y faire face au cas où.
Les deux grands scénarios étaient diamétralement opposés : tout se passe plutôt bien ou tout se passe très mal !
Dans le premier cas, on savait qu’une fois la mise en prod faite, les utilisateurs allaient probablement avoir des questions sur les nouvelles pages ou des suggestions : selon leurs spécificités métiers, ils utiliseraient le produit selon des scénarios ou cheminements auxquels on n’aurait peut-être pas pensés lors du développement. On a donc mis en place un système de remontée d’informations auprès de toutes les équipes de Skello (via Slack et JIRA), puis l’équipe Tech se chargeait de qualifier ces requêtes via les responsables dont on a parlé plus haut. On parle de qualification par priorité : est-ce que c’est un changement urgent à faire ? Est-ce que ça peut attendre et si oui, combien de temps ? Est-ce une attente produit de clients qui espéraient qu’on aille encore un peu plus loin dans cette refonte ? En fonction de critères définis, ces demandes sont soit traitées instantanément, soit elles passent dans des sprints normaux (cycles de développement de l’équipe tech) dans l’esprit d’amélioration continue.
L’autre scénario, l’opposé, était aussi envisagé : l’activation ne se passe pas bien du tout ! Suite à l’activation, nous avions envisagé le cas où de trop grandes parties du site ne fonctionnaient pas correctement, que de trop gros bugs soient remontés, que les performances globales du site n’étaient pas au niveau, et donc que nous aurions dû faire un rollback. Le rollback, c’est quand on arrête la mise en prod de la nouvelle version et qu’on garde l’ancienne version. Ce qui aurait été un échec.
Aussi, nous nous étions fixés plusieurs limites temporelles pour décider si un rollback était nécessaire : si au bout de 24h rien de très critique n’avait été remonté, alors on refaisait un point 48h après. Si rien n’avait été remonté de problématique, un nouveau point était fait en fin de semaine. A chaque fois, nous étions de plus en plus confiants sur le fait que la migration s’était correctement passée, et que le spectre du rollback s’éloignait.
Au final, tout s’est vraiment très bien passé, il y a eu quelques petits correctifs à faire rapidement, mais rien de bien méchant. Nous étions prêts, les process clairs et compris de tout le monde, donc malgré quelques petits coups de chaud, tout s’est très bien déroulé.
Parmi les 3 grands Framework front existant (React, par Facebook, Angular, par Google et VueJS), on a choisi VueJS.
Le fait que VueJS soit gratuit et open source nous permet d’avoir l’indépendance sur notre projet. Cette technologie n’est pas portée financièrement par une grosse entreprise, ce qui peut être un inconvénient pour la vélocité de son développement, mais un gros avantage quant au fait qu’elle ne prendra pas une autre direction du jour au lendemain, et donc n’impacte pas notre projet Skello. VueJS est portée par une grande communauté qui ne sert qu’à elle-même, et non pas les intérêts d’une autre entreprise. Techniquement, c’est aussi un Single File Component, où sont regroupés le template (le html), les scripts (javascript) et le design (css), quand d’autres frameworks séparent ces 3 composants d’une page dans différents fichiers. C’est plus simple à comprendre et il est plus facile de monter en compétences sur cette technologie.
Coté backend, on n’a rien touché en termes d’architecture, on est restés sur du RubyOnRails!
