Il existe plusieurs outils commerciaux pour faciliter la gestion de configurations dans un contexte de développement. Ces outils peuvent être groupés sous le vocable global de gestionnaires de configurations, et incluent des produits comme Visual SourceSafe (voir aussi ceci, ceci et ce texte un peu moins gentil), CVS ou son petit cousin WinCVS (au sujet de CVS, vous pouvez lire ceci, ceci et ce texte un peu moins gentil; pour la version serveur de WinCVS, voir ceci), et d'autres comme Subversion, BitKeeper (utilisé pour gérer l'évolution du noyau de Linux), un projet à code ouvert dont on me dit du bien, GNUArch ou des projets commerciaux tels que CodeJock ou SourceGear.
Je n'ai personnellement utilisé aucun de ces produits; mon expérience se limite à l'emploi de produits maison dans des entreprises soumises à des contraintes un peu particulières. Je ne peux donc promouvoir aucun produit en particulier, et je ne peux pas non plus me montrer garant de la qualité de l'un ou l'autre dans cette liste (qui n'est, évidemment, pas exhaustive).
Il existe beaucoup de gestionnaires de configuration, chacun avec ses avantages et ses inconvénients. L'important est de comprendre à quoi servent ces outils et d'en tirer profit. Passé ce stade, exploiter un outil ou l'autre devient une question de syntaxe ou de préférences personnelles face aux modes de fonctionnement de l'un ou de l'autre.
Un gestionnaire de configurations prend son sens dès que le besoin se fait sentir d'assurer un suivi du développement fait pour un ou plusieurs projets. Ceci permet de tracer un historique des modifications,de comprendre les modifications qui ont été apportées à un fichier, d'assurer l'imputabilité des gens modifiant quelque fichier que ce soit, et permet de revenir en arrière lorsque des modifications sont faites qui entraînent des conséquences négatives.
Ainsi, on s'attend d'un tel outil à ce qu'il garde en note :
Pour qui travaille seul, un gestionnaire de configurations est un filet de protection contre des erreurs ou des accidents bêtes (modification à un fichier qui tourne mal... où est la copie de sauvegarde? Ai-je fait une copie de sauvegarde? Laquelle des copies de sauvegarde devrais-je utiliser pour retomber sur mes pattes?). Le gestionnaire de configuration offre ainsi l'équivalent pour un développeur du Undo qui nous rend la vie si agréable dans la plupart de nos logiciels.
Pour le développement en équipe, les gestionnaires de configuration sont pratiquement indispensables, surtout--mais pas exclusivement--dans les produits monolithiques. Un changement apporté dans un module ou dans un sous-programme peut sembler inoffensif lorsque testé par la personne ayant rédigé le changement, parce que ses tests portent sur ce qu'elle connaît ou présume être à risque, mais peut entraîner des dégâts importants en situation d'utilisation réelle (lorsque d'autres se servent du produit une fois modifié).
Évidemment, en milieu industriel, l'imputabilité est une chose importante: quand ça ne fonctionne pas, quand on prend du retard, il devient vite essentiel de pouvoir retracer les gens à l'origine des irritants et des défauts. Et on ne parle même pas ici de l'importance de pouvoir revenir en arrière lorsque les clients se présentent pour une démonstration et que la plus récente version d'un ou plusieurs modules est considérée instable...
L'emploi d'un gestionnaire de configurations se fait habituellement comme suit :
L'insertion d'un fichier dans un gestionnaire de configuration entraîne un estampillage du fichier, estampillage pouvant être fait à même le code source (sous forme de l'insertion d'un commentaire). L'estampe inclut de l'information quant à la version du fichier, quant à la plus récente date de modification, peut-être aussi quant à sa taille, etc.
L'insertion d'un fichier dans une configuration peut être acceptée ou refusée non seulement pour des raisons d'authentification (de droits), mais aussi pour des raisons d'incompatibilité de version (tentative d'insérer une version périmée par-dessus une plus récente, par exemple). Les règles varieront légèrement selon les gestionnaires.
À partir de cette base, plusieurs variantes locales sont possibles. Entre autres, un gestionnaire peut permettre à plusieurs individus d'extraire un même fichier d'une configuration pour travailler de manière concurrente, ou ne laisser qu'à un seul individu à la fois le droit de modifier un fichier donné dans une configuration donnée. Les particularités des uns et des autres parmi ces gestionnaires ont pour effet de développer des écoles de pensée et de préférences selon les modalités, les us et les coutumes locales.
Les gestionnaires de configurations apparaissent habituellement comme des systèmes de fichier un peu particuliers, respectant habituellement des structures arborescentes comme on en retrouve dans la plupart des systèmes de fichiers conventionnels, dans lesquels les fichiers sont répartis en fonction des projets dans lesquels ils sont utilisés.
La capacité de déplacer ou de copier des fichiers dans un arbre ou l'autre d'un gestionnaire de configurations fait partie des fonctionnalités qui distinguent les gestionnaires les uns des autres.
Il n'est pas dit qu'un gestionnaire de configurations gardera intact et dans son format d'origine tout fichier qui y est inséré. Il n'est pas non plus dit que les arbres de projets dans un gestionnaire de configuration seront de réels répertoires. Règle générale, pour des raisons d'espace, un gestionnaire de configurations voudra souvent compresser les fichiers ou ne garder que des listes incrémentielles de changements pour limiter la redondance (et les besoins en espace) sur disque.
Le fait qu'un gestionnaire de configurations soit (sur disque) plus près d'une base de données (BD) que d'un système de fichiers explique que la plupart d'entre eux offrent leur propre interface personne/ machine (IPM), texte ou graphique, pour nous permettre de naviguer à l'intérieur et pour nous permettre d'y insérer/ d'en extraire des fichiers.
Évidemment, il faut que le gestionnaire de configurations puisse reconstituer tout fichier sur demande. On n'aurait pas confiance en un gestionnaire de configurations qui mangerait nos documents, après tout.
Les gestionnaires de configuration responsabilisent les développeurs qui sont appelés à documenter leurs changements et à tenir à jour lerus sources et, par ricochet, la configuration de leurs produits.
Dans des projets très complexes ou très coûteux, surtout si le logiciel développé est rattaché à l'exploitation d'un matériel dédié et devant être disponible, stable et utilisable selon des horaires précis, on chargera parfois une (ou plusieurs) personne(s) de remplir la tâche de spécialiste d'intégration.
Le/ la spécialiste d'intégration sera responsable de la qualité et de la stabilité de la configuration logicielle (et parfois matérielle) en utilisation sur un site d'intégration donné. Les développeurs qui apporteront des modifications à la configuration seront responsables de la stabilité résultante du système, mais le spécialiste d'intégration validera le bon fonctionnement dans son ensemble et, lorsqu'un problème surviendra, sera responsable d'identifier le module (ou les modules) fautif(s) et de le(s) remplacer par une version antérieure, jugée stable.
Un retour en arrière d'un module peut entraîner une cascade de conséquences sur d'autres modules dépendant des modifications les plus récentes à la configuration. Les erreurs inattendues surviennent souvent en l'absence des gens qui en sont responsables--car, après tout, s'ils avaient prévu le coup, ils auraient laissé une version différente dans la configuration.
Sachant tout cela, on comprendra que les qualités exigées d'un spécialiste d'intégration incluent patience, disponibilité (un système complexe, ça peut planter la veille de Noël; le spécialiste d'intégration héritera souvent d'un téléphone cellulaire ou d'un téléavertisseur) et une facilité à retracer, tel un détective, la source des erreurs dans du code qu'il n'a pas écrit. On confiera une tâche de ce genre à des gens qui connaissent bien les gens, les outils et les langages utilisés dans la compagnie, sinon la tâche devient rapidement très difficile à réaliser.
En retour, considérant la pression, les horaires irréguliers, la propension à travailler les jours fériés et le surtemps pris de manière générale, les spécialistes d'intégration sont souvent bien payés.
Pour en savoir plus...
