« 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