Aller au contenu

L’environnement technique de Neayi

Je profite de la mise à jour de notre environnement pour prendre le temps d’écrire quelques mots sur notre environnement technique…

La plateforme Triple Performance est construite autour de deux briques logicielles : Mediawiki d’une part (le logiciel qui fait tourner Wikipedia), et une brique « back-office » développée à partir d’un framework Laravel.

L’ensemble de notre environnement logiciel tourne avec Docker, ce qui permet d’isoler chaque composant logiciel. Grâce à Docker, nous pouvons reproduire parfaitement l’environnement de production sur le poste de chaque développeur, qu’il s’agisse de postes Windows ou Linux. Par ailleurs, Docker permet de configurer finement chaque élément de l’environnement (par exemple la version de PHP ou de MySQL) en configuration. On peut ainsi tester des montés de version en changeant un chiffre dans un fichier.

Notre stack docker est composée d’une dizaine de containers, qui jouent chacun son rôle propre : Traefik en proxy pour l’ensemble des connexions entrantes, gère aussi la mise à jour des certificats HTTPS (grâce à l’extension ACME), les briques logicielles sont chacunes servies par leur propre container (PHP FPM, Nginx), et nous avons ensuite des containers pour MySQL, Redis, ElasticSearch, ainsi que quelques services logiciels comme Parsoid, qui permet la conversion de fichiers HTML vers wikitext et inversement.

Si vous êtes curieux, l’ensemble de notre configuration Docker est sur github. Un point intéressant, notre plateforme est conçue depuis le départ pour permettre des mises à jour « à la volée », les images Docker étant générées automatiquement sur Github au fur et à mesure des ajouts fonctionnels. Merci à Michel Roca d’Huytéza pour son aide et ses conseils sur ces sujets !

Nous opérons selon le principe de « document by configuration », ce qui veut dire que l’ensemble des processus de mise à jour, création d’instance, migration, etc… sont exécutables par une seule commande.

La brique back-office est développée en TDD (Test Driven Development) : pour chaque nouvelle fonctionnalité on créé d’abord un test, et la fonctionnalité est réputée terminée quand le test « passe ». En réalité, ce mode de développement oblige une organisation du logiciel et un cloisonnement très propre de chaque couche (implémentation, modèle, contrôleurs, vues, stockage). Merci à Guillaume Cozic pour ça, son expertise à été précieuse !

Un mot enfin sur Github : dans la mesure où nous considérons que la connaissance doit être un commun, de même nous considérons que le code logiciel doit être ouvert et open source. Le choix de Github s’est imposé rapidement. Github nous permet non seulement de partager et de travailler collaborativement avec les différents intervenants techniques (code source, gestion des bugs, notifications, intégration avec Slack, etc…), mais permet en outre la connexion avec des systèmes d’intégration continue et de validation de la qualité du code, qui sont assez fantastiques. Nous sommes ainsi alertés si une de nos dépendance n’est plus à jour et s’il y a de nouvelles alertes de sécurité qui nécessitent une action de notre part. Pour les développeurs qui travaillent sur notre projet, cette ouverture leur sert à la foi comme démonstration de leur expérience, mais les oblige aussi à maintenir une qualité de code et de process, sachant que l’ensemble de ce qu’ils font reste visible de tous.

Une petite anecdote sur l’impressionnante puissance de l’open source : lors d’un test de mise à jour nous avons eu un problème bizarre (CSS non générée). Le fichier CSS affichait alors une erreur « SCSS compile error » :

  • Je me suis permis d’ouvrir, à 13h09, un bug au niveau du projet MediaWiki qui permet de construire notre habillage.
  • À 13h50 j’avais une première réponse.
  • À 15h37 un bug est alors ouvert par cette dernière personne dans la librairie causant le problème.
  • À 17h32, trois personnes étaient dans la discussion, et la décision a été prise de faire une nouvelle release de cette librairie intégrant le correctif.
  • Deux jours plus tard cette release était disponible – sans rien toucher à notre code l’ensemble s’est remis à fonctionner. Difficile de faire mieux ! (Merci aux contributeurs, dont on notera qu’ils sont largement européens !).