Je ne résiste pas à poursuivre l’analyse de tranches de vie que je reçois :

Hier matin, nouvelle génération : Ca plante toujours à la compilation. Conclusion : quand y a un mec qui dit dans son mail de mise- à-disposition des entrées « attention j’ai modifié le nom d’un fichier, faut mettre à jour les scripts » c’est pas pour faire chier, c’est bien parce qu’il faut mettre à jour les scripts.

C’est bien plus court que la fois précédente, et pourtant c’est toujours aussi riche en enseignements. Sur chaque projet, il ya un processus plus ou moins officiel de livraison : méls, bordereau de livraison, etc. Ils permettent deux choses :

1. À celui qui le rédige, de vérifier qu’il n’oublie rien avant de passer le relais ;
2. À celui qui le reçoit, de prendre connaissance d’informations complémentaires éventuelles en plus des informations habituelles qui permettent d’adresser le travail quotidien.

Du coup, négliger cet acte de livraison, par l’un ou l’autre des parties, est nécessairement source de soucis.

Deuxième point, plus directement destiné à l’intégrateur : les index de production, c’est la lie ! Quel est le but premier d’un index de production ? Lister les fichiers qui seront pris en compte dans l’exécutable final. À l’origine, l’intention est louable : ça donne l’illusion de maîtriser son périmètre de production. Je dis illusion parce que ça ne fait pas tout : identifier un nom de fichier ne permet pas d’en donner la version. Et puis surtout, avec le temps, un index de production, ça sert aussi à plein d’autres choses. Ça sert à filtrer le contenu du système de fichiers. Ça sert à ranger proprement ce qui ne l’est effectivement pas dans le système de fichier. Ça sert à cacher ce qui ne devrait pas être visible de tous. Ça sert d’excuse quand ce n’est pas à jour. Un vrai cache-misère. D’autant plus que par construction un index de production est obsolète et un frein à la productivité. Une surcouche inutile à l’encontre de la logique, qui fait bien souvent dire « mais il est là mon fichier, vas-y, compile, [propos ordurier exclusivement destiné au sélectionneur de l'Équipe de France, donc censuré]« 

Quel outil doit être le garant du contour de la production, c’est-à-dire la liste des fichiers et leurs versions ? Il y a un piège, il faut deux outils :

1. Le gestionnaire de version de code source, qui permet toujours de retrouver un certain état global du projet à partir d’un identifiant approprié pour peu qu’il ait été posé ;
2. La chaîne de production, basée sur des règles simples, comme par exemple : tout fichier dans SRC est compilé, et tout entête trouvé dans le répertoire INC est public.

Utilisez les outils pour ce qu’ils sont sensés faire, et tout de suite, ça ira mieux.

La vie d’intégrateur est un régal quotidien. J’en veux pour preuve ce témoignage récent :

Hier soir, génération du nouveau loadable. Le sous-traitent me dit tout content que le loadable est prêt et que tout s’est bien passé. Du coup je l’envoie sur le banc pour le tester et vérifier que tout va bien.

Trente minutes après, je pars sur le banc pour voir comment ça va. Impeccable, tout marche bien. Je leur demande quand même de vérifier quelques variables système pour valider l’état global, ça marche pas trop bien finalement. On regarde alors les messages BITE : l’OS fait rebooter notre appli en boucle, finalement ça marche vraiment pas top.

Après une petite vérification du download et de la version installée qui vont bien, on regarde le contenu du loadable. Et la, surprise, l’exe a une taille de 0 … forcément ça marche vraiment pas du tout.

Du coup on relance la compile, et effectivement ca plante à cause de symboles non définis … c’est vraiment dommage que personne n’ait vérifié les traces de compile avant de faire un loadable, de le charger sur banc et de lancer l’appli …

Après analyse, ce ne sont pas les bons fichiers qui ont été utilisés pour la génération … heureusement qu’on avait le banc pour détecter ce problème !

Truculent. Tout simplement truculent. Pourtant, même de cette tranche de vie, on peut apprendre plein de choses. Déjà on peut se demander à quoi riment les tests. Rien ne tourne, mais le constat est sans appel : « OK ! Tout marche bien navette ! ». Ensuite mis à part qu’il faille quatre ingénieurs pour générer, transférer, télécharger et exécuter un exécutable de taille nulle, on peut simplement se dire que si aucun fichier n’avait été généré, la spirale infernale aurait été stoppée net. Même avec les mauvais fichiers sources. Et là, désolé, mais c’est la faute de l’intégrateur. Il est impératif de ne rien mettre à disposition quand on n’est pas certain de ce que l’on propose. Il est déjà suffisamment pénible d’identifier a posteriori un produit (mais au fait, qu’est-ce qui tourne sur le banc ?).