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.