J’ai les boules… je viens de faire le merge du boulot que j’ai abattu depuis pas loin de 3 mois (merge = transfert du code d’une branche de développement à une autre - en l’occurrence depuis ma branche “privée” vers la branche “publique” visible et utilisable par tous les développeurs). Ce soir à 23h se lancera la compilation journalière, base de travail pour tous les développeurs du projet et donc dans laquelle mes modifications seront pris en compte. Lundi l’action première de tous les développeurs sera de télécharger cette nouvelle version et de l’utiliser comme base de travail pour la journée… autant dire que si j’ai foiré quelque part… je le saurais avant même d’atteindre mon poste de travail!
Depuis début Mars, je travaille à la refonte d’une des parties centrales de notre logiciel alias le moteur de règles qui gère les relations entre les objets lors des actions - copier/couper/déplacer/coller - effectuées par l’utilisateur. Pour vous faire une idée de ce que je fais, imaginez une table (composée de 4 pieds d’un plateau) et un verre vide posé sur celle-ci. Au moment de leurs créations respectives au sein du logiciel, chaque objet a émis un certain nombre de règles du genre “je suis un pied, je peux être ajouté sous un plateau” ou “je suis un verre, je peux être posé sur un plateau” ou “je suis un plateau je peux avoir au maximum 4 pieds, et si j’en ai moins de 4 ca va barder”. Dès lors, que se passe t-il si l’utilisateur copie un pied de table et essaye de le coller sous ce même plateau? Le moteur de règle va interdire l’action au regard de la règle émise par le plateau (max 4 pieds). De même, si l’utilisateur essaye de couper le plateau, le moteur de règle va dire “tss tss, il y a un verre qui repose sur toi, si tu t’en va il va se péter la gueule alors je t’interdit de t’en aller”.
Vous l’aurez compris, je m’occupe en fait d’assurer la “consistance” de la structure qui est entrain d’être construite; je fais en sorte que jamais une action qui aboutisse à une structure “bancale” - on parle de configuration illégale ou inconsistante - soit effectuée. Autant dire que si qqch foire dans mon code, l’erreur est susceptible d’impacter simplement… tout le monde!
Pour minimiser les erreurs et maximiser la qualité du logiciel, nous travaillons avec un ensemble de règles de test. Pour chaque morceau de code (ou plutôt chaque fonctionnalité élémentaire), un scénario de test automatique doit être écrit, scénario qui vient alors gonfler la masse des tests à effectuer avant tout “merge”. Le script global contient plus de 1800 tests et demande près de 4h d’exécution, mais permet d’éviter les effets de bord (qu’une modification à un bout du logiciel ne casse qqch à l’autre bout sans le savoir).
Depuis une semaine, je laisse tourner le script toutes les nuits et décortique les résultats pendant la journée pour m’assurer qu’aucun des tests négatifs obtenu n’est dû a mes modifications… ce soir j’ai eu le go de mon chef alors voila c’est mergé! Après tant de tests, je suis (presque) convaincu que tout ira bien, mais malgré tous je ne peux m’empêcher d’imaginer le pire… si qqch foire lundi promet d’être funky!
Recent Comments