Choisir quand lancer : surmonter les défis chez Transloadit
Il y a quelques semaines, l’équipe s’est réunie dans l’une de ces minuscules fenêtres de conférence Skype pour discuter d’une question importante : devions-nous lancer Transloadit dans sa version actuelle ?
Par ordre d’importance, voici les problèmes auxquels nous faisions face à ce moment-là :
- Nous étions bloqués sur Node
v0.1.28 - Nous avions très peu de tests unitaires
- La conception du système présentait quelques points faibles
Pourtant, nous savions aussi que le système était capable de choses étonnantes. Certains de nos testeurs alpha l’utilisent pour envoyer de grandes vidéos et en produire jusqu’à 32 fichiers de résultat (filigranes et miniatures de différentes tailles), qui sont ensuite envoyés vers S3. Cela représente plus de 100 Jobs internes que nous lançons et gérons en parfaite harmonie, tout cela grâce à la formidable puissance de Node.
Dans cette optique, nous avons décidé de nous lancer lors de la prochaine JSConf. Jusqu’à la semaine dernière, nous avons travaillé d’arrache-pied pour atteindre cet objectif. Nous avons intégré le paiement par carte bancaire au site web, élaboré une excellente offre et un modèle tarifaire, et passé des heures à traquer les derniers bugs du système.
Et puis… tout est parti en vrille.
Nous avions remarqué que notre serveur Node plantait toutes les 1 ou 2 semaines, mais nous l’attribuions à une erreur de notre part et nous ne pensions certainement pas que cela deviendrait un problème majeur. Eh bien, ce fut finalement le cas. En testant certaines des Assemblies les plus intensives mentionnées plus haut, nous avons constaté que le serveur plantait plus souvent. Il s’avère que l’ancienne version que nous utilisons comporte de graves problèmes dans le code réseau. Quand l’un de ces problèmes survient, la dernière chose que l’on voit est :
(evcom) recv() Success
Et puis le serveur s’arrête. Sans segfault ni détails.
Aïe ! Un an de dur labeur en dehors des heures de bureau partait soudain en fumée. Nous pourrions déployer des efforts considérables pour traquer ce bug, voire le corriger. Mais en réalité, nous corrigerions alors le mauvais problème.
Le vrai problème, c’est que nous utilisons une ancienne version de Node. Et si c’est le cas, c’est parce que nous n’avons pas suivi les paroles d’Uncle Bob :
« Professionnalisme : le médecin s’est-il lavé les mains, avez-vous écrit vos tests ? »
Si notre code avait été bien couvert par les tests, mettre à jour Node n’aurait pas posé de gros problème. Refondre certains points de conception de l’application non plus.
Nous faisons donc maintenant ce que nous aurions dû faire dès le départ : réécrire notre ancienne
version en une nouvelle, entièrement testée et construite sur la future version de Node 0.2.0. Cela
prendra un peu de temps, mais heureusement, nous pouvons réutiliser une grande partie du travail
acquis à force d’essais et d’erreurs sur la version 1.
Nous tenons à remercier toutes celles et ceux qui ont testé la version 1, et nous avons hâte de vous tenir informés de l’avancement de la version 2.
P.-S. Finalement, je n’ai pas pu me rendre à la JSConf à cause du volcan. Nous y verrons un signe. 😄