Les meilleures pratiques
en matière de gestion de configuration logicielle

Laura Wingerd et Christopher Seiwald
Perforce Software

[ English | Deutsch ]

Avant-propos

Lorsqu'il s'agit de déployer de nouveaux outils de gestion de configuration logicielle (GCL), les personnes chargées de la mise en œuvre s'escriment parfois à perfectionner les activités subtiles, tout en remettant à plus tard, par inadvertance, les pratiques rudimentaires largement utilisées avec leurs emplois ou outils précédents. Il en résulte une bévue proprement exécutée. Cet article met en avant les meilleures pratiques qui résultent de l'expérience acquise par ses auteurs en matière de déploiement d'outils GCL.

1. Introduction

Selon une idée répandue, c'est l'utilisateur qui fait l'efficacité d'un outil et non l'inverse. En tant que fournisseurs d'outils de gestion de configuration logicielle (GCL) et de consultants auprès d'éditeurs de logiciels, on nous interroge souvent quant aux méthodes à suivre en matière de GCL - autrement dit, comment optimiser le déploiement de logiciels de GCL. Pour répondre à cette question, nous pouvons nous appuyer sur bon nombre d'expériences directes et indirectes en matière de GCL. Les expériences directes sont celles que nous avons nous-mêmes vécues en tant qu'anciens développeurs et responsables de programmation ; les expériences indirectes résultent des témoignages de réussite et d'échec de nos clients, que ce soit à travers l'utilisation de nos produits (Perforce) ou celle d'autres outils de GCL.

Le tableau suivant présente six domaines généraux de déploiement GCL, ainsi que quelques pratiques de base à conseiller dans chacun de ces domaines. Chacun des éléments cités dans ce tableau est expliqué dans les chapitres suivants.

 

Espaces de travail Là où les développeurs construisent, testent et déboguent.	Ne pas partager les espaces de travail. Ne pas travailler en dehors des espaces de travail gérés. Ne pas utiliser de "jello views". Rester cohérent par rapport à la Codeline. Archiver régulièrement.
Codeline Ensemble canonique de fichiers source.	Définir une politique pour chaque Codeline. Attribuer à chaque Codeline un propriétaire. Avoir une Mainline.
Branches lvariantes de la Codeline.	Ne créer des branches (ou ramifier) qu'en cas de nécessité. Ne pas copier plutôt que de créer une branche. Créer une branche en cas d'incompatibilité d'une politique. Ramifier le plus tard possible. Ramifier au lieu de figer.
Propagation des modifications Répercuter les modifications d'une Codeline à une autre.	Apporter des modifications originales dans la branche qui a le moins évolué depuis la ramification. Propager tôt et souvent. Confier l'opération de fusion à la personne appropriée.
Constructions Transformer les fichiers source en produits.	Source + outils = produit. Archiver tous les éléments d'origine. Séparer les objets de construction des éléments d'origine. Utiliser des outils de construction courants. Construire souvent. Conserver les journaux et les résultats de construction.
Processus Règles régissant tout ce qui précède.	Effectuer le suivi des groupes de modifications. Effectuer le suivi des propagations d'un groupe de modifications. Distinguer les demandes de modifications des groupes de modifications. Attribuer un propriétaire à tout élément. Utiliser des documents vivants.

 

2. Espace de travail

L'espace de travail, c'est là où les ingénieurs modifient les fichiers source, construisent les composants logiciels sur lesquels ils œuvrent, et où ils testent et déboguent ce qu'ils ont construit. La notion d'espace de travail est commune à la plupart des systèmes de GCL ; il est parfois appelé "sandbox" (ou bac à sable), c'est le cas dans Source Integrity, ou "vue" dans ClearCase et Perforce, par exemple. La modification de fichiers gérés du référentiel du système de GCL commence par la modification de fichiers dans un espace de travail.

Voici quelles sont les meilleures pratiques en ce qui concerne les espaces de travail :

• Ne pas partager les espaces de travail. Un espace de travail doit avoir une fin unique. Il peut s'agir d'une zone d'édition/construction/test pour un seul développeur, ou encore d'une zone de construction/test/sortie utilisée dans le cadre d'une sortie de produit. Le partage d'un même bureau engendre généralement une certaine confusion. Il en va de même pour les espaces de travail. Par ailleurs, le partage des espaces de travail compromet la capacité des systèmes de GCL à suivre l'activité par utilisateur ou par tâche. Les espaces de travail et l'espace disque qu'ils occupent étant peu coûteux, il est inutile de perdre du temps à essayer de les conserver.
• Ne pas travailler en dehors des espaces de travail gérés. Votre système de GCL ne peut suivre le travail en cours que lorsqu'il est réalisé à l'intérieur des espaces de travail gérés. Ainsi, les utilisateurs travaillant à l'extérieur des espaces de travail restent sur le rivage de la rivière d'informations qui coule devant eux. Par exemple, les systèmes de GCL utilisent généralement des espaces de travail pour faciliter la communication entre les développeurs qui œuvrent sur des tâches apparentées. Vous pouvez voir ce qui se passe dans les espaces de travail de vos collaborateurs, et eux peuvent voir ce qui se passe dans le vôtre. Si vous devez quitter votre poste de travail de façon urgente, votre espace de travail correctement géré sera la seule chose que vous pourrez oublier. Exploitez de vrais espaces de travail.
• Ne pas utiliser de "jello views". Un fichier situé dans votre espace de travail ne doit en aucune manière être modifié à moins que vous ne soyez clairement à l'origine de cette modification. Par "jello view", on entend un espace de travail dans lequel les modifications de fichiers sont causées par des événements extérieurs dont vous n'avez pas la maîtrise. Un espace de travail créé sur une arborescence de liens accédant à des fichiers d'un autre espace de travail est un exemple type de "jello view". Dans ce cas, les fichiers de votre espace de travail sont modifiés aussitôt que les fichiers sous-jacents sont mis à jour. Les "jello views" sont une source de désordre pour les développeurs de logiciels. Les symboles de débogage dans les fichiers exécutables ne correspondent pas aux fichiers source, de mystérieuses recompilations interviennent dans des reconstructions supposées insignifiantes, et les cycles de débogage ne convergent jamais — ceci n'est qu'un aperçu des problèmes rencontrés. Préservez la robustesse et la stabilité de vos espaces de travail en les configurant de telle sorte que les utilisateurs puissent décider de l'instant où leurs fichiers seront modifiés.
• Rester cohérent par rapport à la Codeline. En tant que développeur, la qualité de votre travail dépend de sa coordination avec le travail des autres. En d'autres termes, à mesure que des modifications sont enregistrées dans la Codeline, vous devez mettre à jour votre espace de travail et intégrer ces modifications aux vôtres.

Entant qu'ingénieur en GCL, il vous appartient de faire en sorte que cette opération de mise à jour de l'espace de travail soit simple et dépourvue de procédures piégeuses et fastidieuses. Si les développeurs découvrent que la mise à jour de leur espace de travail ne présente pas de difficultés majeures, ils réaliseront cette opération plus souvent et les problèmes d'intégration ne s'accumuleront pas aux diverses échéances du projet.

• Archiver régulièrement. L'intégration de votre travail de développement à celui des autres personnes exige également de votre part que vous archiviez les modifications aussitôt qu'elles sont prêtes. Une fois que vous avez terminé une tâche de développement, archivez vos fichiers modifiés de manière à rendre votre travail disponible aux autres.

3. Codeline

Dans ce contexte, la Codeline est l'ensemble canonique des fichiers source nécessaires à la production de votre logiciel. En règle générale, les Codelines sont ramifiées, et les branches correspondantes se développent en différentes Codelines représentant différentes versions. Les meilleures pratiques concernant les Codelines sont les suivantes :

• Définir une politique pour chaque Codeline. L'objet d'une politique de Codeline est de définir l'utilisation appropriée et les archivages acceptables pour la Codeline, et constitue le manuel d'utilisation essentiel de la GCL de la Codeline. Par exemple, la politique d'une Codeline de développement doit indiquer qu'elle ne concerne pas une version de produit ; de la même manière, la politique d'une Codeline de Release doit limiter les modifications aux correctifs de bogues approuvés 1. La politique peut également indiquer comment documenter les modifications archivées, ce qu'il convient d'examiner, les tests à effectuer, et les attentes en matière de stabilité de la Codeline après archivage. La politique est un élément crucial dans le cadre d'un processus de développement de logiciels documenté et réalisable, et une Codeline sans politique n'est pas contrôlable du point de vue de la GCL.
• Attribuer à chaque Codeline un propriétaire. Une fois que vous aurez défini la politique d'une Codeline, vous rencontrerez rapidement des cas particuliers où la politique est inapplicable ou ambiguë. Les développeurs confrontés à ces ambiguïtés se tourneront vers la personne responsable de la Codeline pour trouver des solutions. En l'absence de responsable attitré, les développeurs auront tendance à solutionner eux-mêmes le problème sans documenter la méthode employée. Ou ne disposant pas d'informations suffisantes sur la Codeline pour trouver une solution raisonnable, ils se contenteront d'atermoyer. Il est possible d'éviter cet écueil en désignant un propriétaire de la Codeline, qui la guidera tout au long de sa durée de vie utile. Avec cet objectif plus large, le propriétaire de la Codeline pourra faciliter le franchissement des zones de turbulence inhérentes au développement de logiciel en conseillant les développeurs à propos des exceptions dictées par la politique définie et en les documentant.
• Avoir une Mainline. La "Mainline" (ou "tronc") est la branche d'une Codeline qui se développe indéfiniment. La Mainline constitue une destination ultime pour la quasi-totalité des modifications — qu'il s'agisse de correctifs de maintenance ou de nouvelles fonctions — et représente l'évolution principale et linéaire d'un logiciel. Les Codelines de version et les Codelines de développement sont des ramifications qui partent de la Mainline, et le travail effectué au niveau de ces branches est propagé en retour sur la Mainline.

La figure 1 représente une Mainline (appelée "main") d'où partent plusieurs branches correspondant à des lignes de version ("ver1", "ver2" et "ver3") et des lignes de développement de fonctions ("projA", "projB" et "projC"). Les développeurs travaillent au niveau de la Mainline ou d'une ligne de développement de fonction. Les lignes de version sont réservées aux tests et correctifs importants et sont à l'écart du brouhaha du développement. L'ensemble des modifications soumises aux lignes de version et aux lignes de développement de fonction sont finalement fusionnées dans la Mainline.

L'approche qui consiste à "promouvoir" les Codelines présente des inconvénients ; c'est le cas lorsqu'une Codeline de développement passe au rang de ligne de version et qu'une nouvelle branche de Codeline de développement est créée. Par exemple, la figure 2 illustre la promotion d'une Codeline de développement au rang de Codeline de version ("ver1"), à laquelle est greffée une nouvelle Codeline de développement ("projA"). Chaque Codeline de version débute comme Codeline de développement, et le développement se déplace d'une Codeline à une autre.

Le schéma de promotion souffre de deux handicaps : (1) il nécessite de modifier la politique régissant une Codeline, ce qui n'est jamais facile à communiquer à l'ensemble des personnes concernées ; (2) il contraint les développeurs à transférer leur travail en cours sur une autre Codeline, opération fastidieuse et génératrice d'erreurs. 90 % des "processus" GCL forcent la promotion des Codeline pour compenser l'absence d'une Mainline.

Lorsque vous utilisez un modèle de Mainline, le processus s'en trouve rationalisé et simplifié. En effet, les espaces de travail et les environnements des contributeurs sont stables pendant toute la durée d'exécution de leurs tâches, et aucuns frais administratifs additionnels ne sont enregistrés à mesure que les logiciels gagnent en maturité.

4. Ramification

La ramification, c'est-à-dire la création de variantes d'autres Codelines, est l'aspect le plus problématique de la GCL. Il existe des différences marquées entre les fonctionnalités de ramification offertes par les divers outils de GCL, et les différentes politiques ne font qu'accroître les disparités. Les instructions suivantes s'avèrent particulièrement utiles lorsqu'il s'agit de créer des branches (elles indiquent également quand s'abstenir d'en créer) :

• Ne créer des branches (ou ramifier) qu'en cas de nécessité. Chaque branche implique du travail supplémentaire — plus de constructions, plus de modifications à propager aux différentes Codelines, plus de fusions de fichiers source. Si vous gardez cela à l'esprit chaque fois que vous envisagez de créer une branche, vous éviterez peut-être de faire pousser des branches inutiles.
• Ne pas copier plutôt que de créer une branche. Plutôt que d'utiliser le procédé de ramification de votre outil de GCL, vous avez également la possibilité de copier un jeu de fichiers source d'une Codeline et de les archiver dans un autre en tant que nouveaux fichiers. Ne croyez pas pour autant éviter les coûts de ramification en recourant simplement à la copie. La copie présente toutes les difficultés de la ramification (entités supplémentaires et complexité accrue) sans offrir les avantages liés à la prise en charge de la ramification par votre système de GCL. Ne vous méprenez pas : même les copies en "lecture seule" transmises à un autre groupe de développement "uniquement pour consultation" vous seront souvent retournées avec des modifications. Lorsqu'il s'agit de scinder tout ou partie d'une Codeline, créez une branche à l'aide de votre système de GCL. >
• Créer une branche en cas d'incompatibilité d'une politique. Il existe une règle simple qui permet de déterminer si une Codeline doit être ramifiée : elle doit l'être si ses utilisateurs ont besoin de politiques d'archivage différentes. Ainsi, un groupe de version de produit pourra-t-il avoir besoin d'une politique d'archivage qui impose des tests rigoureux, alors qu'une équipe de développement aura besoin d'une politique qui permette un archivage fréquent de modifications partiellement testées. Cette divergence de politiques appelle à la création d'une branche de Codeline. Lorsqu'un groupe de développement ne souhaite pas voir les modifications apportées par un autre groupe de développement, il s'agit également d'une forme d'incompatibilité de politiques : chaque groupe doit disposer de sa propre branche.
• Ramifier le plus tard possible. Pour réduire au minimum le nombre de modifications à propager d'une branche vers une autre, retardez autant que possible la création d'une branche. Par exemple, si la branche de la Mainline intègre l'ensemble des nouvelles fonctions d'une version et que ces fonctions sont prêtes, procédez à autant de tests et de corrections de bogues que possible avant de créer une branche de version. Chaque bogue corrigé dans la Mainline avant la création de la branche de version sera une modification de moins à propager entre les branches.
• Ramifier au lieu de figer. D'un autre côté, si les tests nécessitent de figer une Codeline, les développeurs qui ont des modifications à apporter devront attendre la fin des tests avant de pouvoir intégrer ces modifications. Dans ce cas, ramifiez la Codeline assez tôt à l'avance pour permettre aux développeurs d'archiver leur travail et d'avancer.

5. Propagation des modifications

Après avoir ramifié les Codeline, vient le moment de vous confronter aux difficultés de la propagation des modifications de fichiers à travers les branches. Il s'agit souvent d'une tâche délicate dont on peut rester maître en respectant certains principes.

• Apporter des modifications originales dans la branche qui a le moins évolué depuis la ramification. Il est beaucoup plus simple de fusionner une modification à partir d'un fichier proche de l'ancêtre commun qu'à partir d'un fichier qui a divergé considérablement. En effet, la modification apportée au fichier qui a divergé peut reposer sur des modifications qui ne sont pas propagées, et ces modifications indésirables risquent de faire échouer le processus de fusion. Vous pouvez minimiser la complexité de la fusion en apportant les modifications d'origine dans la branche la plus stable. Par exemple, si une Codeline de version est ramifiée à partir d'une Mainline, toute correction de bogue doit être apportée d'abord dans la ligne de version avant d'être fusionnée dans la Mainline. Si vous corrigez le bogue d'abord dans la Mainline, vous serez peut-être amené à revenir sur les autres modifications incompatibles qui ne sont pas censées être intégrées à la Codeline de version au moment de la fusion.
• Propager tôt et souvent. Lorsqu'il est possible de propager une modification d'une branche vers une autre (autrement dit, si la modification ne doit pas violer la politique définie pour la branche cible), faites l'opération sans tarder. Les propagations de modifications par lots qui interviennent tardivement peuvent donner des fusions de fichiers extraordinairement complexes.
• Confier l'opération de fusion à la personne appropriée. La complexité de l'opération de propagation de modifications peut être amoindrie en confiant cette tâche à l'ingénieur le plus à même de résoudre les conflits de fichiers. Ainsi, les modifications pourront être propagées par (a) le propriétaire des fichiers cibles, (b) la personne qui a apporté les modifications d'origine, ou (c) quelqu'un d'autre. Mais (a) ou (b) feront un meilleur travail que (c).

6. Constructions

La construction consiste à élaborer un logiciel opérationnel à partir des fichiers source d'origine. Les constructions sont plus faciles à gérer et moins sujettes à des problèmes lorsque certains principes-clés sont respectés :

• Source + outils = produit. Les seuls ingrédients nécessaires à une construction sont les fichiers source et les outils dans lesquels ils sont intégrés. Les procédures mémorisées et les pense-bêtes n'ont pas de place dans cette équation. À fichiers source et outils de construction identiques, le produit obtenu doit toujours être le même. Si vous avez rédigé des procédures d'installation, automatisez-les en scripts. Si vous disposez de procédures d'installation manuelle, documentez-les en instructions de construction. De même, documentez toutes les spécifications d'outils, y compris celles concernant le système d'exploitation, les compilateurs, les fichiers "include", les bibliothèques de liens, les programmes "make" et les chemins des exécutables.
• Archiver Lorsqu'un logiciel ne peut pas être reproduit de façon fiable à partir des même ingrédients, il y a des chances pour que la liste des ingrédients soit incomplète. D'une manière générale, les ingrédients manquants sont les fichiers "makefile", les scripts d'installation, les scripts de construction, les instructions de construction et les spécifications d'outils. Tous ces éléments constituent la source à partir de laquelle vous construisez. Rappelez-vous : source + outils = produit.
• Séparer les objets de construction des éléments d'origine. Organisez vos constructions de telle sorte que les répertoires contenant les fichiers source d'origine ne soient pas pollués par les objets de construction. Les fichiers source d'origine sont ceux que vous créez "à partir d'un processus original réfléchi" par l'intermédiaire d'un éditeur de texte, d'un générateur d'application ou de tout autre outil interactif. Les objets construits correspondent à l'ensemble des fichiers créés lors du processus de construction, y compris les fichiers source générés. Ces objets ne doivent pas être copiés dans vos répertoires de code source. Construisez-les plutôt dans une arborescence de répertoires indépendante. Cette séparation permet de limiter le champ d'action du système de GCL aux répertoires contenant uniquement la source. Elle a également pour effet de circonscrire les fichiers volumineux et/ou extensibles à un emplacement unique, ce qui simplifie la gestion de l'espace disque pour les constructions.
• Utiliser des outils de construction courants. Les développeurs, les ingénieurs chargés des tests et les ingénieurs en construction de logiciels doivent utiliser les mêmes outils de construction. Une perte de temps importante est occasionnée lorsqu'un développeur ne peut pas reproduire un problème rencontré lors d'un test ou que le produit fini est différent du produit qui a été testé. Rappelez-vous : source + outils = produit.
• Construire souvent. Le fait de construire régulièrement de bout en bout, en procédant à des tests de régression (version de validation), présente deux avantages : (1) ces constructions révèlent les problèmes introduits par les archivages, et (2) elles produisent des bibliothèques de liens et d'autres objets de construction qui peuvent être utilisés par les développeurs. Dans l'idéal, les versions de validation doivent être mises en œuvre après chaque archivage, mais dans le cas d'une Codeline active, il est plus pratique de les effectuer en dehors des heures de travail, généralement, la nuit. Chaque branche de Codeline doit faire l'objet de constructions et de tests de régression réguliers, fréquents et complets, même si la date de sortie du produit n'est pas imminente.
• Conserver les journaux et les résultats de construction. Quel que soit l'objet construit que vous avez produit, vous devez être en mesure de retrouver les opérations exactes (p.ex., l'indicateur de fin du compilateur et le texte de commande de lien) qui ont abouti à sa dernière version correcte. Archivez les résultats et les journaux de construction, notamment les versions de fichiers source (p.ex., une étiquette), les infos concernant la version des outils et du système d'exploitation, les résultats du compilateur, les fichiers intermédiaires, les objets construits et les résultats des tests. Vous pourrez ainsi vous y reporter ultérieurement. À mesure que les projets logiciels d'envergure avancent, les composants passent d'un groupe à un autre, et le groupe qui les reçoit n'est pas forcément en mesure de se lancer immédiatement dans la construction de nouveaux composants. Le moment venu, le groupe devra accéder aux journaux de construction antérieurs pour diagnostiquer les problèmes d'intégration qu'ils rencontrent.

7. Processus

On ne saurait traiter en détail la question de la conception et de la mise en œuvre des processus de GCL en quelques lignes. Il faudrait pour cela un, voire plusieurs articles complets, et bon nombre de travaux de ce type ont déjà été réalisés par ailleurs. De plus, votre entreprise a des objectifs et des contraintes spécifiques, dont on n'a pas connaissance, et qui seront pris en compte dans le processus que vous mettrez en œuvre. Toutefois, l'expérience nous a montré que certains concepts en matière de processus doivent être à la base de toute mise en œuvre de GCL :

• Effectuer le suivi des groupes de modifications. Même si à chaque fichier de Codeline correspond un historique des modifications, chaque modification de l'historique n'est utile que dans le contexte d'un ensemble de fichiers apparentés. Il vous sera impossible de répondre à la question "Quels sont les fichiers source qui ont été modifiés suite à la modification apportée au fichier foo.c ?" si vous n'avez pas effectué le suivi des groupes de modifications ou des jeux de fichiers liés par une modification logique. Les groupes de modifications, par opposition aux modifications de fichier distinctes, sont la manifestation visible du développement d'un logiciel. Certains systèmes de GCL effectuent le suivi des groupes de modifications à votre place ; si ce n'est pas le cas du vôtre, écrivez une interface de ce type.
• Effectuer le suivi des propagations de groupes de modifications. L'un des avantages évidents du suivi des groupes de modifications est la possibilité de propager de façon très simple les modifications logiques (p.ex., correctifs de bogues) d'une branche de Codeline à une autre. Toutefois, la simple propagation de groupes de modifications à travers les branches ne suffit pas ; vous devez être en mesure de pouvoir identifier les groupes de modifications qui ont été propagés, les propagations qui sont en cours et les branches de Codeline qui sont susceptibles d'émettre ou de recevoir des propagations. À défaut, vous ne pourrez jamais répondre à la question "Le correctif du bogue X se trouve-t-il dans la Codeline de la version Y ?" Répétons-le, certains systèmes de GCL assurent le suivi des propagations de groupes de modifications à votre place, alors que d'autres nécessitent de votre part l'écriture d'une interface spéciale. Enfin, vous ne devez jamais utiliser la commande "diff" pour déterminer si un groupe de modifications a été propagé entre les Codeline.
• Distinguer les demandes de modifications des groupes de modifications." Tâches à accomplir" et "Tâches accomplies" sont deux entités de données différentes. Par exemple, un relevé de bogues est une entité de type "Tâche à accomplir", tandis qu'un correctif de bogue est une entité de type "Tâche accomplie". Votre processus GCL doit établir une distinction entre les deux, car de fait, il peut exister une relation à origine unique et destinations multiples entre les demandes de modifications et les groupes de modifications.
• Attribuer un propriétaire à toute entité. Chaque entité (processus, politique, document, produit, composant, Codeline, branche ou tâche) de votre système GCL doit avoir un propriétaire. En les représentant, les propriétaires donnent vie à ces entités ; avec un propriétaire, une entité peut se développer et mûrir. Les entités sans propriétaire sont comparables à des obstacles sur un chemin de fourmis : les fourmis les contournent comme si de rien n'était.
• Utiliser des documents vivants. Les politiques et les procédures que vous mettez en œuvre devraient être décrites dans des documents vivants ; autrement dit, il faudrait que la documentation relative à vos processus soit aussi facilement accessible et tout autant sujette à des mises à jour que votre code source géré. Les documents qui ne sont pas accessibles sont inutiles ; les documents qui ne peuvent pas être mis à jour le sont presque autant. Les documents relatifs aux processus doivent être accessibles à partir de tous vos environnements de développement : depuis votre propre station de travail, depuis celle de n'importe quel autre collègue, et depuis votre ordinateur privé. Par ailleurs, ces documents doivent pouvoir être mis à jour sans difficulté, et les mises à jour doivent être mises à disposition dans la foulée.

8. Conclusion

Les meilleures pratiques en matière de GCL, comme dans tout autre domaine, paraissent toujours évidentes une fois qu'on les a mises en œuvre. Même si les pratiques abordées dans cet article se sont avérées efficaces dans notre cas, il convient de reconnaître qu'elles ne peuvent pas toutes être présentées dans un document de cette longueur. Nous avons présenté les pratiques qui offrent le plus de résultats mais qui semblent pourtant être souvent outrepassées.

Dans l'optique d'améliorer ce document, les suggestions d'ajout de nouvelles pratiques et les remarques constructives sur les pratiques présentées ci-dessus sont les bienvenues.

9. Publications de référence

Berczuk, Steve, "Configuration Management Patterns", 1997, disponible à l'adresse: http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ConfigurationManagementPatterns.

Compton, Stephen B, Configuration Management for Software, VNR Computer Library, Van Nostrand Reinhold, 1993.

Continuus Software Corp., "Work Area Management", Continuus/CM: Change Management for Software Development. Disponible à l'adresse: http://www.continuus.com/developers/developersACE.html.

Dart, Susan, "Spectrum of Functionality in Configuration Management Systems", Software Engineering Institute, 1990. Disponible à l'adresse: http://www.sei.cmu.edu/technology/case/scm/tech_rep/TR11_90/TOC_TR11_90.html

Jameson, Kevin, Multi Platform Code Management, O'Reilly & Associates, 1994.

Linenbach, Terris, "Programmers' Canvas: A pattern for source code management" 1996. Disponible à l'adresse : http://www.rahul.net/terris/ProgrammersCanvas.htm.

Lyon, David D, Practical CM, Raven Publishing, 1997.

McConnell, Steve, "Best Practices: Daily Build and Smoke Test", IEEE Software, Vol. 13, N° 4, juillet 1996.

van der Hoek, Andre, Hall, Richard S., Heimbigner, Dennis et Wolf, Alexander L., "Software Release Management", Proceedings of the 6th European Software Engineering Conference, Zurich, Suisse, 1997.

Remarques

1.

Des politiques de Codeline raisonnables: Codeline de développement: les modifications apportées au code provisoire peuvent être archivées; les composants affectés doivent pouvoir être construits. Codeline de sortie: le logiciel doit être construit et passer les tests de régression avec succès avant l'archivage: archivages limités aux correctifs de bogues: aucune fonction ou fonctionnalité nouvelle ne peut être archivée: après archivage, la branche est figée tant que le cycle d'assurance qualité n'est pas terminé. Mainline: tous les composants doivent être compilés et liés, et passer les tests de régression avec succès; les nouvelles fonctions abouties et testées peuvent être archivées.