Le confiseur

Retours d'expérience sur l'intégration logicielle

Archives pour la catégorie Intégration logicielle

La folie est contagieuse car un fou en forme d’autres

juin 12

Publié par seventh dans Intégration logicielle | Aucun commentaire

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 ?).

Il faut changer les pas de danse quand on change la cadence

mar 21

Publié par seventh dans Intégration logicielle | Aucun commentaire

« Intégration continue, mon chef crie ton nom ! » Et il a bien raison d’en vouloir, car force est de constater qu’il est plus facile de casser que de réparer, quelque soit le domaine. C’est pourquoi « changer sans tout péter » est une danse à la chorégraphie toute particulière. Enfilez vos claquettes, et suivez-moi.

Première option : la tectonik

Perrin change l’interface A en B. Non seulement il doit valider sa nouvelle altération toute seule, mais en plus il va prendre sur lui et plutôt que d’embêter tout le monde, il va également modifier le code de tous ceux qui consommaient A pour désormais utiliser B. Ça peut marcher :

  • si le passage de A à B est suffisament simple pour que ça ne prenne pas une ère géologique. Typiquement, si c’est automatisable ;
  • si le code des consommateurs est suffisament stable pour que Perrin puisse espérer livrer un jour ;
  • si Perrin a suffisamment d’aura pour être autorisé à aller triturer toute l’application plutôt que son simple domaine.

Ça fait beaucoup de conditions, mais pour des modifications légères, c’est tout à fait sheiladéquat.

Deuxième option : le ballet classique

Cette fois, Perrin ne remplace pas A par B, mais fourni B en plus de A. Ensuite, il pousse au cul demande aux autres de gentiment migrer de A vers B. Quand tout le monde l’a fait, Perrin fait disparaître A. C’est déjà plus élégant. Mais il ne faut pas oublier de finir les travaux ! Bien souvent, la phase de nettoyage est délaissée faute de réel problème perceptible immédiatement. Qui se soucie du code mort ? Là encore, ça marche :

  • si A et B peuvent coexister ;
  • si le passage de A à B n’est pas trivial ;
  • si B peut attendre.

Cette technique est bien plus élaborée que la précédente, puisqu’elle nécessite que les gens se parlent, ce qui n’est pas toujours gagné. Mais ça permet à chacun d’aller à son rythme et évite de râler après les blocages induits par les erreurs des uns et des autres.

Troisième option : la danse moderne

Alors là, on a intérêt à être un connaisseur, parce que c’est bien la seule raison pour laquelle ça paraît pas mal. C’est bien entendu issu de la méthode précédente, mais de là à parler d’amélioration … À ne jamais vouloir bloquer personne, toutes les interfaces sont en double, plus personne ne sait plus ce qui est obsolète ou encore d’actualité.

Allez, sans aller jusque là, disons que ça fait déjà deux mois que A et B cohabitent. L’architecte vient de finir son Biba, et il se dit que, finalement, en cherchant à améliorer, il a pondu B, alors que, toutes les lectrices lui accordent, c’était de C dont le projet avait besoin ! Qu’à cela ne tienne, l’intégrateur va se charger de faire la migration, c’est son boulot à cette sale faignasse graisseuse, non mais hé !

Sauf que, déjà, tout le monde n’est pas passé de A à B, alors de A à C (ce qui est sûrement encore plus compliqué vu le cri strident qu’à fait la veste de l’architecte quand il l’a retournée), et en même temps de B à C … Que faire ? Tout simplement, commencer par finir la transition de A à B, et il sera ensuite toujours temps d’introduire C (attention ! « C » n’est pas le nom de l’architecte !)

Du coup, la belle technique du ballet classique, dont le principal intérêt était de permettre à chacun d’évoluer à son gré, se retrouve prise à défaut puisque personne n’a cherché à rejoindre les rangs : on force donc la rejointe des retardataires, ce qui fait bien entendu perdre du temps au plus grand nombre. C’est exactement ce qu’on voulait éviter.

Vous l’avez compris, cette technique n’est qu’un rebus dégénéré de la précédente, et il faudra essayer d’éviter de tomber dans ce travers.

Je veux bien être plus souple, mais il y a des limites : je ne suis pas danseuse au Lido non plus ! – B. Takam, intégrateur

Tout est bon dans le cochon

déc 30

Publié par seventh dans Intégration logicielle | Aucun commentaire

Je le rappelle parce que c’est important : la différence fondamentale qu’il y a entre vous, l’intégrateur, et eux, les systémiers, c’est que vous savez que la vie du projet n’est pas une longue présentation en quarante-huit planches. Là où d’autres pensent qu’il n’y a qu’une mécanique bien huilée, vous savez qu’il y a aussi parfois de la sueur et des contournements pas toujours maîtrisés. Un exemple au hasard (mais alors, complet) : l’altération qui dure à l’infini.

Au début, tout va bien : Perrin récupère un fait technique à corriger, il se crée son petit espace de développement, tente de le corriger, y arrive même, et vous le donne pour intégration. Mais voilà, le processus d’intégration étant parfois ce qu’il est, avec son lot de lenteurs et de priorités, dont l’altération de Perrin ne fait pas partie d’ailleurs, Perrin se dit qu’il aurait également plus vite fait de corriger un fait technique lié (ou pas) dans le même espace de développement, ça lui fera économiser du temps. Alors il se lance, et vos ennuis commencent ici.

Rappel : vous espérez avoir des altérations confinées, succintes, en quelque sorte atomiques, respectant le schéma « une altération par sujet ». Ainsi vous savez intégrer continuement, au fil de l’eau, bref, vous êtes lean sans y prêter attention. C’est d’ailleurs ce que vous avez mis dans vos transparents pour expliquer votre travail à ceux qui vous donnent des ordres mais qui ont jusqu’à oublié ce qu’était le développement logiciel, s’ils l’ont jamais su.

Perrin est en train de s’asseoir sur votre joli principe, et compromet le travail de toute une équipe. Il commence à ajouter des dépendances là où il n’y en avait pas grâce à sa nouvelle correction. S’il continue ainsi, c’est bientôt lui qui décidera comment les autres développements devront s’adapter à ses modifications pathétiques. Il est temps que cela cesse.

Mais attention, inutile de clouer Perrin au pilori. Je sais, c’est tentant. Oh ! oui, je le sais. Pourquoi est-ce qu’il ne faut pas éviscerer cet âne batté de Perrin au milieu de l’open-space en récitant des formules cryptiques à la gloire de Loki ? Parce que j’aime à croire que les gens ne font pas exprès de nuire à autrui, même si c’est au plus grand nombre. Ce qui nous amène à trois cas de figure :

  • Perrin est effectivement, pleinement, globalement, complètement abruti. Il ne comprend rien à rien. C’est toujours sa mère qui lui lace ses chaussures. La dernière fois qu’il a joué tout seul au Trivial Pursuit, c’est son hamster qui a gagné. Bref, s’il est là, c’est qu’il n’y avait plus de place à la Qualité, alors essayez juste de faire en sorte qu’il ne vous importune plus, en devenant responsable de clôture des revues par les pairs par exemple, ça le préparera à son futur métier dès qu’une place se libèrera.
  • Perrin travaille pour Al-Qaida, courant tropézien historique. C’est un véritable nuisible, conscient de ses actes. Vous trouverez plein de choses sur ThinkGeek pour lui rendre la monnaie de sa pièce.
  • Perrin ne savait pas. Vous ne lui avez pas expliqué la différence entre le bien et le mal, ce que vous attendiez de lui, vous ne lui avez récité que ses droits et pas ses devoirs, bref, vous n’avez pas fait votre boulot ! Ça pique hein ? C’est pourtant le cas le plus probable.

Alors, que faire ? D’abord, arrêtez les frais dès que vous vous en apercevez : mettez le holà au cataclysme que vous prépare Perrin, stoppez-le net dans ses expérimentations. Un bon indicateur de dérive est le suivant :

Si une altération vous est proposée dans plus de trois formes différentes, c’est qu’il y a un problème de fond.

Par contre, vous allez devoir trouver un moyen d’intégrer ses monstrueuses altérations devenues monolithiques, car même s’il a eu tort, personne ne paiera à nouveau pour réparer en amont, séparer à nouveau tel que vous l’entendiez ses différentes altérations. C’est comme ça, je vous assure. Et ça coûtera plus cher au final. Mais puisque je vous dis que je le sais !

Ensuite, et c’est le point le plus important,

Présentez à toute l’équipe le processus d’intégration dans son intégralité tout en commençant à l’habituer au fait que le monde n’est pas fait que de noir et de blanc.

Alors, et seulement à partir de ce moment-là, si Perrin ou un autre vous refait la même, vous pourrez calmement vous diriger du pas de l’être sûr de son fait et dans son droit vers le bureau de l’accusé, et le défénestrer manu militari sans faire de vague ni même souffrir une quelconque et vaine protestation. Le vieux sanglier a la rancune tenace.

Tags: , ,

Il ne faut pas juger le sac à son étiquette

nov 21

Publié par seventh dans Intégration logicielle | Aucun commentaire

Rien de tel qu’un mauvais processus de gestion des faits techniques pour ruiner un projet. Or, le monde est scindé en deux catégories étanches : ceux qui ont vu la Vierge (ou Ganesha, ou Raël), et ceux qui se sentent concernés par leur emploi. Généralement, ce sont les premiers qui ont pour charge de poser les fondations qui permettront à l’immense majorité que consitituent les seconds de travailler. Le processus de gestion des faits techniques en fait partie. Ce sont également les premiers qui ne comprennent pas que le doute soit permis quand une correction est proposée.

Petite expérience récente : prenez un processus de gestion des faits techniques qui ne permette pas de se tromper. Exemple : s’il existe une production officielle intégrant une proposition de correction pour un fait technique donné, alors ce fait technique doit être dans un état dont le nom peut varier mais souvent évocateur : clos, fermé, réglé, terminé, effacé ou encore abattu. Notez bien l’inversion de la relation de causalité : « j’ai une tentative de correction, c’est donc que le problème est réglé ». Si, par un étrange coup du sort, votre équipe ne contenait pas que des développeurs capables de produire 100.000 lignes d’assembleur sans bogue (ce qui serait très étonnant dans notre monde de l’ultra-performance), vous voilà bien.

Perrin vient vers vous avec son correctif pour le fait technique 12327, il a remplacé le signe ‘-’ par le signe ‘^’ dans la fonction qui doit couvrir l’exigence PQ-3265.b : « Étant donné les constantes K_TRUC et K_MACHIN dont les valeurs sont précisées en annexe B.3, le système doit fournir le résultat de leur multiplication à l’utilisateur, conformément à la norme IEEE-754 par temps de pluie ». Perrin est vaseux. Il s’est couché tard pour avoir voulu assister à la finale de « La maison des secrets ». C’est bien Léo, Académicien de 23 ans, qui a gagné le concours d’ingestion de gaspacho. Perrin est soulagé, mais fatigué. Malgré tout, c’est jour de livraison. Et oui, on livre tous les jours désormais. Quand ce n’est pas au client, c’est à la qualité, ou à l’équipe système, ou au restaurateur du site. Alors vous imaginez bien : la production sort, elle est fournie avec force bolduc à son destinataire, le FT 12327 est mort et enterré, on passe tous à autre chose.

Sauf que… le problème initial n’est pas si bien corrigé que ça. Que faire ? Le processus ne permet pas de rouvrir le FT 12327, d’autant plus qu’il a été livré au client. Et puis on ne va pas avoir tort quand même, surtout si c’est patent, vu que c’est le client lui-même qui s’est rendu compte que le dit problème n’était pas franchement corrigé. Alors on va ouvrir un autre fait technique, le 24055 (oui, en deux jours, on peut en trouver des problèmes vous savez). S’enclenchent alors la double-comptabilité et le dialogue de sourds. « Le FT12327 a été corrigé, le problème dont vous me parlez c’est le FT24055″. Et puis, songez que si vous êtes payé au fait technique corrigé, c’est extrêmement juteux, puisque le FT12327 est effectivement clos, tout le monde pourra le vérifier. Les indicateurs sont impitoyables.

Il ne faut jamais confondre intégration de correctif et validation fonctionnelle associée.

Ce n’est pas parce qu’une tentative de correction existe que le problème est dissout. Tout le monde peut se tromper, y compris en corrigeant un problème. Il faut donc se méfier d’une correction non testée. Les effets de bord, ça existe. Mais c’est là que le bât blesse : à vouloir parler vite, on utilise des formules courtes qui occultent la réalité des choses. Ce que l’on appelle au quotidien « une correction » n’est jamais qu’une proposition. Ce simple oubli a de vastes conséquences et est source de problèmes multiples : incompréhension, excès de confiance, puis atteinte de la fierté de celui qui propose une correction incomplète ou ratée, bref, de l’effet Joule à tire-l’arigot.

Je ne crois pas non plus qu’on puisse toujours éviter les doublons dans une base de fait technique. « Oui, je connais ce problème, on l’a vu il y a trois mois, c’est amusant qu’il ressurgisse. Si je me souviens bien, c’est le FT 504″. Un bon processus de gestion des faits techniques doit pouvoir permettre d’en rouvrir, ne serait-ce parce que c’est admettre qu’on peut se tromper. Ça évitera quelques doublons et facilitera bon nombre de communications. À l’inverse, interdire la réouverture force à dupliquer les problèmes et pousse inexorablement à une confiance excessive et aux conversations de type bingo « Le 17542 ? Non, tu dois vouloir parler du 18309. Ou le 18776 peut-être ? »

Mais ça se saurait aussi si les fidèles de Marie lisaient ces lignes.

Tags: ,

Qui fait deux fois naufrage ne doit pas s’en prendre à la mer

nov 1

Publié par seventh dans Intégration logicielle | 2 commentaires

Il y a fort à parier que vous vous soyez déjà frotté à la pierre philosophale du développement logiciel : la génération automatique de code. Ça c’est une vraie bonne idée de manager moderne ! Un développeur, ça coûte des sous, ça geint, c’est lent, mais alors, vraiment, ça fait du code tout sale, qui colle aux doigts, qui marche moyennement d’ailleurs, de façon tellement médiocre qu’il doit aussi écrire des tests qui vont avec, tests qu’il va également falloir valider… Vous le voyez le serpent qui se mord la queue et qui coûte des sous ? Du code généré automatiquement, c’est trop mieux : pas besoin de tests en face, juste un bouton à appuyer et des milliers, voire des millions de lignes de code viendront remplir les disques durs automagiquement ! Le code généré a forcément raison : s’il y a malgré tout un bogue, ce sont les entrées du générateur qui sont moisies (modèle UML, spécifications, conception, que sais-je ?) En plus, ça augmente la productivité de toutes ces sales faignasses au regard bovin qui constituent la masse salariale. Alors, elle est pas belle la vie ?

Disons, oui et non. Il y a généralement deux stratégies :

  1. génération préliminaire de code, puis maintenance manuelle des pièces (comprendre fichiers) générées ;
  2. génération systématique de code à partir des entrées.

La première est souvent très pratique et permet de mettre en place une grosse architecture en place rapidement, mais peut mal vieillir, surtout si la génération a lieu bien avant que les entrées ne soient mûres. La seconde est bien plus pernicieuse, donc amusante au quotidien : les développeurs n’ont plus à maintenir le code opérationnel, mais uniquement les entrées. Ça, c’est la théorie. En pratique, ni le générateur, ni les entrées ne sont mûres. Par entrées j’entends les entrées pures du générateur citées plus haut, mais aussi potentiellement l’architecture, la plateforme, etc. Pourtant les impératifs du projet restent ce qu’ils sont : on corrige, on ajoute et on avance, rapidement s’il-vous-plaît. Alors, autant sans générateur toute la capacité de modification d’un composant se concentre à un seul niveau (le code opérationnel), autant avec, on en obtient trois : les entrées, le générateur … et le code généré bien entendu ! Et c’est l’entropie de l’univers qui se félicite, la complexité de gestion vient de gagner deux facteurs d’échelle, comme ça.

Un générateur de code doit produire du code humainement maintenable et débogable.

Il sera toujours temps de discuter toutes les stratégies de génération dans d’autres articles, mais le fondamental ci-dessus ne doit jamais être oublié. Que faire de millions de lignes de code auxquelles on ne comprend rien ? Comment modifier manuellement et rapidement du code généré (si si, ça peut s’avérer intéressant à petites doses) si le générateur duplique, triple les références aux mêmes choses sous différentes formes ? Un générateur de code, même certifié, ne fait que ce qu’on lui demande : il transpose des idées depuis un formalisme vers un autre. C’est un outil, et comme tel, il doit aider et non contraindre. De la même manière que vous pouvez comprendre ce que vous lui donnez à manger (diagramme UML et consorts), vous devez comprendre facilement le code produit.

Tags: ,