Le confiseur

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

Archives pour la catégorie Intégration logicielle

Il ne faut qu’une étincelle pour faire un grand incendie

oct 12

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

Et si on se faisait tous confiance ? Après tout, pourquoi pas : vous avez mis sur pied un processus en béton armé, tous ces gentils développeurs vous livrent des altérations mûrement testées, maintes fois vérifiées, par plusieurs personnes en plus. Donc tout va s’intégrer gentiment sans poser de problème, c’est évident. Les outils sont cantonnés au strict nécessaire, tout est verrouillé, bref, personne ne peut se planter. Et bien si : vous.

Oui, vous là, qui dormez au troisième rang. Je vous ai vu avec votre air satisfait de président de fan-club de Gérard Majax : non, la pierre philosophale du logiciel n’a toujours pas été découverte. Vous auriez tort de croire en vos propres propos rassurants pour la hiérarchie. Le développeur est fourbe, et aura toujours une raison de ne pas vous écouter. Le pire, c’est que ce sera pour une bonne raison : votre processus générique a peu de chance de résoudre tous les cas particuliers.

La seule personne dont vous pouvez légitimement ne pas vous méfier, c’est vous-même. Tous les autres sont des scélérats !

Là où ça se complique, c’est que le dit développeur ne va pas forcément penser à vous communiquer toutes les subtilités et les stratagèmes qu’il aura utilisé, au mieux par omission. Il ne faut donc pas lui faire confiance, il est le mal ! Il vous faut donc avoir à disposition une batterie d’instruments secrets, qui n’existeront officiellement pas, mais qui vous permettront rapidement de lui apprendre l’auto-coprophagie et à itérer sur ses livraisons. Secrets, car il ne faut pas que les développeurs y aient accès trop tôt, l’apprentissage par l’erreur étant la seule voie possible vers la lumière. Quand ils auront bien digéré leurs erreurs, il sera alors toujours temps de leur révéler vos ficelles, pour leur faire gagner du temps. D’ici là, méfiez-vous, l’ennemi est déjà dans la place.

Tags: ,

Qui conduit dans le fossé y tombera le premier

sept 13

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

J’ai constaté encore récemment l’étonnement que pouvait susciter chez certains une phrase du genre : « Ha non ! La nouveauté que tu cherches est dans la production n°27, mais pas dans la 28. » Allons bon. On fait du développement logiciel incrémental, et pourtant les productions se suivent mais ne se ressembleraient pas ? À cela, tout simplement je répondrai : « Oui. Et pire, c’est voulu. » Mais laissez-moi le temps de m’expliquer, avant de m’envoyer la sécurité pour que je débarasse mon bureau et libère ma place de parking.

Tous les jours, différentes équipes de développement vont vous fournir des altérations du logiciel : nouveau développement, correction de bogue, mise-en-place d’interfaces pour le futur, etc. Si vous mettez tout ça dans une seule et même production, vous n’avez simplement aucune plus-value ! Le plus probable est que vous obteniez un exécutable qui plante rapidement, voire très rapidement. Ce qui fait qu’une seule altération empêche tous les autres d’être testés. Aprêtez-vous à ouvrir le bureau des plaintes.

Justifiez votre salaire, et aidez les développeurs :

Faites plusieurs productions à la fois, en séparant les différentes altérations en plusieurs groupes.

Par exemple, les moins risquées ensemble (les correctifs simples), et les nouveaux développements à part, voire jusqu’à isoler chacun. La limitation haute étant, évidemment, la capacité de production de vos infrastructures. Ainsi, vous minimiserez le risque qu’une minorité bloque une majorité.

Une fois que vous aurez obtenu un certain nombre d’altérations validées, vous pourrez alors les intégrer toutes dans un seul et même exécutable, vérifier sommairement son fonctionnement, et publier une nouvelle version stabilisée. Ce qui, vous le constaterez, est bien plus apprécié que de publier des versions de moins en moins fonctionnelles.

Tags: , ,

Chose promise est dûe

sept 6

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

C’est jour de livraison. Aux temps immémoriaux d’un monde archaïque, vous auriez déjà stabilisé un exécutable il y a une semaine, et celui-ci serait depuis inspecté minutieusement par l’équipe de validation. Personne n’aurait cherché à introduire des correctifs de dernière minute, car chacun sait qu’il vaut mieux une livraison quasiment fonctionnelle aux défauts caractérisés à une I.B.M.I. (Infâme Bouillie Mal Identifiée). Réveillez-vous, ce temps-là est révolu : vous êtes devenu un programmeur de l’extrême, du genre agile, à développer selon les principes de l’industrie automobile (!) Il est grand temps pour vous de redécouvrir la joie du stress de dernière minute.

Petite remise en situation : nous sommes le jour J, il est 8h du matin, et l’exécutable ne démarre même pas. Il va falloir stopper la machine à perdre rapidement si vous ne voulez pas que toute l’équipe passe à la Gatling ! En ce qui vous concerne, voici le commandement qui vous incombe :

Ne travaillez jamais sur un coin de table.

Ça a l’air stupide, n’est-ce pas ? Pas plus que de mettre au point un exécutable à l’arrache (seule méthode fonctionnelle, à défaut d’être efficace) et de devoir avouer quelques jours plus tard qu’on ne sait plus quel est le code qui a servi à la livraison. Ou comment l’exécutable a été obtenu. «Mais enfin !», me diriez-vous, «seul un imbécile en arriverait là !» Ah bon ? Pas si sûr. Vu le maelström qui va se mettre en place jusqu’à tard dans la nuit, vous avez intérêt à vous assurer que personne ne sortira des ornières que vous aurez tracé. Bien entendu, oubliez momentanément une bonne partie de votre processus habituel de développement/livraison. Mais ne lâchez pas les fondamentaux :

L’intégralité du code servant à produire l’exécutable final est connu de l’outil de gestion de configuration.

L’exécutable livré est obtenu uniquement à partir de la chaîne de production officielle.

Vous pouvez même pousser le vice à fournir un gigantesque espace de patch que tout le monde ira bidouiller comme il le souhaite, mais cet espace est en conf. Demain, vous pourrez (faire) remettre au propre tout ça, demander des livraisons officielles des composants qui intègrent ces correctifs de dernière minute. Les développeurs pourront alors se poser la question si tel ou tel patch écrit en urgence est vraiment pertinent. Mais au moins ils auront une base claire de travail. Sans cela, vous passerez la semaine qui suit la livraison à retrouver vos petits, sous les quolibets de l’équipe de spécification et les remarques incendiaires des développeurs qui ne comprennent pas pourquoi ils devront faire deux fois le travail. Pas évident à vivre, surtout quand il faut livrer tous les mois.

Tags: ,

À chaque saint sa chandelle

sept 3

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

Loutil des gagnants

L'outil des gagnants

N’hésitez jamais à contredire l’architecte du projet. Déjà parce que ça fait un bien fou. Ensuite parce qu’il n’a pas toujours raison, malgré ce qu’il peut penser. L’architecte moyen imagine et définit le logiciel comme il doit être à terminaison, et oublie toutes les étapes par lesquelles celui-ci doit passer avant d’être achevé. Comme une bonne partie des informaticiens, il ne prend pas en compte la problématique de l’intégration. La loi de Murphy étant ce qu’elle est, l’architecte vous pondra à coup sûr une organisation du logiciel qui vous empêchera de l’intégrer. Voilà un premier ennemi clairement identifié et facilement repérable.

Petit exemple récent, bien navrant : un premier livrable, fournissant interface et implémentation homogènes, est fourni par une seule et même personne. Par contre, grâce à la magie de la gestion de configuration, et sur décision de l’architecte qui défini  le découpage modulaire du logiciel, ce code est saupoudré dans tout un tas d’autres composants qui l’hébergent. Donc, ils le relivrent, puisqu’il est chez eux ! Question à deux francs six sous : comment l’intégrateur va-t-il garantir l’intégrité de ce livrable ? Autre question : comment utiliser une nouvelle version de ce livrable sans attendre de relivraison des autres composants ? Parfois, les outils de gestion de configuration déployés sur votre projet pourront vous aider à résoudre ce problème, plus ou moins élégamment, mais toujours de façon un peu alambiquées Un alambic étant de loin le dernier outil dont vous ayez besoin pour sortir un logiciel, soyez ferme, et encore une fois, exigez :

Le logiciel doit être découpé et organisé en composants dissociés livrés indépendamment.

Ne nous méprenons pas, il reste malgré tout à assurer la cohérence des différents bouts de logiciels entre eux (vous n’espériez quand même pas être payé à ne rien faire non mais hé !), mais au moins, chaque bout du logiciel est identifié de façon unique et vu par tous de la même manière.

Vous pourriez rétorquer, comme l’architecte en question, que le premier livrable n’est qu’une chimère, un artifice de travail, et que ce qui compte, c’est ce que publient les autres composants qui chacun embarquent une partie du code. Ça pourrait effectivement être le cas si un dernier composant ne se basait pas uniquement et intégralement sur la soit-disant chimère diluée dans tout le logiciel. Pour ce dernier composant, l’artifice est une réalité concrète, un tout indivisible. Et puis, ce serait de toute façon oublier un peu vite le besoin de cohérence du premier livrable. Refusant d’admettre un seul instant qu’il aurait pu oublier une hypothèse de travail dans son raisonnement parfait par essence, l’architecte, sûr de son fait, vous assène un fantastique « Miroir magique ! De toute façon c’est plus logique d’avoir le découpage que notre bon vouloir aura imposé à terme ! » Certes, mais le projet est encore loin d’être terminé. Si, quand tout marchera parfaitement, l’architecte souhaite ranger les fichiers dans les répertoires qu’il souhaite, vous serez prêt à lui offrir un accès toutes zones. Mais la route est encore longue et sinueuse, la pente plutôt raide… et l’architecte déjà retourné dans son bureau après avoir soigneusement refermé sa porte.

À ce stade de la conversation, Lucifer vient généralement vous tapoter l’épaule en vous souhaitant bon courage d’un air condescendant mais satisfait. L’enfer est pavé de bonnes intentions. Et les architectes s’occupent de l’entretien des voies.

Tags: ,

Ne nous associons qu’avec nos égaux

sept 2

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

Vu ce à quoi vont ressembler vos journées, il est important qu’elles se passent sans énervement excessif. À cela, rien de plus simple : posez vos conditions ! Pas n’importe lesquelles bien sûr, mais au moins celle-ci :

Il faut au moins un responsable derrière chaque livrable, et plus d’un serait pêché.

Rien de plus agaçant en effet que de recevoir un bon de livraison, de se poser une question, voire de n’y rien comprendre, et de vouloir casser le nez en discuter avec… qui justement, si personne n’est identifié derrière cette livraison ? Bien entendu, il y a un piège : généralement, celui qui publie le bon de livraison n’est pas celui qui a fait le code ou connaît les contraintes induites par cette livraison. Celui que vous cherchez n’est pas non plus le responsable de l’équipe, qui gère la planification, les sous et l’avancement. Ou alors c’est un coup de pot inimaginable, vous êtes tombé sur quelqu’un de compétent sur son poste, dépêchez-vous de travailler avec lui avant qu’il ne soit muté à quelque chose de totalement inadéquat pour lui !

Non, il vous faut identifier celui – ou ceux, mais ne rêvons pas – qui connaît tout le contenu de la livraison, ses dépendances et ses implications. C’est cette personne que vous irez voir quand le doute vous étreindra (dois-je intégrer cette version en même temps que la nouvelle version de tel composant ? avez-vous bien pensé à reporter telle partie essentielle du correctif lambda ?) et qui vous répondra à peu de frais, et à coup sûr. Plutôt que de vous envoyer voir Perrin, qui a regardé la partie qui vous intéresse, à moins que ce ne soit Michel…

Et s’il y en a plus d’un qui peut tenir ce rôle, qu’il existe un autre indispensable ? Déjà, il doit toujours être fourré avec le premier. Dans ce cas, c’est facile, ils ne forment qu’une entité. Sinon, essayez de vous adresser toujours au même. Ça légitimera son statut dans le projet sans pour autant dénigrer l’autre. Et ça évite tout bruit de fond (désynchronistation entre eux, désaccord, etc.) C’est d’ailleurs ce qui justifie la seconde partie de la règle, dont voici le corollaire :

Pas plus d’une source d’information par donnée.

Pourquoi tout ceci est si important ? Parce qu’une personne forme à elle seule un consensus, à moins que vous ne travailliez avec des schizophrènes. Si vous posez une question à quelqu’un, il y a toutes les chances du monde qu’elle vous réponde toujours la même chose (jusqu’à ce qu’elle s’énerve. Et là…) Deux personnes sont toujours amenées à discuter un peu, peser le pour et le contre, s’interroger, même par pure réthorique, pour obtenir ce même consensus.  Vous n’avez pas envie d’assister à ces litanies. Donc, si vous identifiez la personne qui a toujours la plus grande probabilité de vous répondre correctement à tous les coups, vous irez de toute façon naturellement poser vos questions à celle-ci. Elle ne vous fera pas perdre votre temps, et vous ne ferez pas en perdre inutilement à toute son équipe. Et oui, tout le projet ne tourne pas autour de vous, ne l’oubliez pas non plus !

Tags: ,