Balinea - Une mise en prod en beauté - 1/3

Nous avons été missionnés pour la refonte from scratch de la plateforme Web de Balinea, une plateforme de vente de soins beauté/bien-être. Je m’appelle Olivier et je suis développeur Symfony chez KNPLabs depuis 2014. J’ai réalisé une mission chez Balinea pendant quasiment deux ans : le projet est en ligne et on peut dire que ma mission s’est terminé avec succès ! Je vais aujourd’hui détailler comment j’ai mené une rupture douce chez Balinea pour apporter des workflows qui assurent la qualité technique et différentes méthodologies pour aider l’équipe à travailler ensemble et faciliter la communication avec le marketing. Vous pouvez me suivre sur Twitter https://twitter.com/RougeMine.

La version précédente de cette plateforme reposant sur un CMS propriétaire, il fallait faire le grand pas entre maintenir en parallèle la plateforme basée sur celui-ci, et l’écriture de la nouvelle version.

Côté technique, le choix s’était porté avant notre intervention sur une Single Page Application, basée sur le micro-framework JavaScript BackBone côté navigateur et Symfony et FOSRESTBundle côté serveur.

Arrivés au constat que ce travail allait devoir se mener sur deux fronts, Balinea a demandé en renfort l’accompagnement de KNPLabs pour cette réécriture, du fait de notre savoir-faire reconnu dans l’utilisation de Symfony notamment.

Un workflow pour assurer la qualité technique

Lorsque j’ai rejoint l’équipe, nous avons discuté des différents moyens possibles d’améliorer le processus de développement. Voici les solutions que nous avons mises en place collectivement et progressivement....

De “Subversion mono-branche” à git et GitHub

Afin d’assurer la migration de SVN vers git, j’ai donné une formation à l’équipe durant une après-midi et l’ai accompagnée ensuite quotidiennement en répondant aux différentes questions ainsi qu’en proposant divers trucs et astuces.

Une fois le code source placé sur un dépôt git, et celui-ci synchronisé avec un compte GitHub privé fraîchement acheté, j’ai pu présenter le principe des Pull Requests et de la revue de code, devenue obligatoire, et requérant l’approbation de deux développeurs avant chaque merge. Les problèmes rencontrés lors des premiers pas avec git n’ont pas été la seule difficulté à gérer. Il a également fallu expliquer le caractère profondément constructif des code reviews : les remarques faites sur le code ont dans un premier temps été parfois interprétées comme des critiques gratuites du travail accompli voire de son auteur.

Avec le temps, il est devenu clair pour toute l’équipe que cela permettait d’homogénéiser le code et de tirer les compétences techniques de tous vers le haut. La revue de code a fini par devenir naturelle et les PRs se sont par ailleurs agrémentées de descriptifs et emojis amusants (et que pourrait-on bien objecter à cela ?  ;-)

De la Single Page Application à pjax : une transformation complète sous le capot, mais invisible pour l’utilisateur

L’équipe Balinea étant spécialisée en PHP, nous avons décidé de réduire au maximum l’utilisation de Javascript et de déporter le plus possible de code vers PHP et Symfony. Il fallait cependant conserver le comportement de “SPA” (Single Page Application) de l’application qui était en cours de développement : quoi que l’on fasse, l’utilisation du middle-office ne devait pas déclencher de rechargement de la page, pour une navigation tout en fluidité.

J’ai pu proposer la mise en place d’une logique inspirée de ce qui se fait chez Basecamp, une entreprise dont le CTO est toujours le David Heinemeier Hansson (dit DHH), génial créateur du framework Ruby on Rails, sans qui nos frameworks modernes seraient sûrement bien différents de ce qu’ils sont aujourd’hui. L’idée était de maximiser au mieux les points forts de l’équipe et de déplacer tout le code possible côté serveur, en générant les vues avec Twig et Symfony, et de remplacer simplement le code HTML du coeur de page de l’application par celui renvoyé par le serveur.

Cette restructuration peut se faire très facilement grâce à des scripts comme pjax, un outil créé par GitHub : celui-ci va intercepter les clics sur les liens, appeler l’URL demandée en Ajax, puis remplacer le code HTML par celui retourné par la page. Grâce à l’API “History” du navigateur, gérée automatiquement par pjax, l’URL de celui-ci est bien mise à jour comme si le lien avait été cliqué : l’utilisateur peut utiliser les boutons “précédent” / “suivant” de son navigateur et recharger sa page. Tout fonctionne comme il se doit.

Lorsque l’on souhaite que la réponse du serveur génère des changements plus subtils qu’un remplacement complet du coeur de page, on a recours à la technique du "Server-generated JavaScript Responses", décrite ici par DHH. Le principe est de renvoyer dans la réponse du serveur des balises de script, qui vont être ajoutées au code HTML de la page dans un