Le point sur la gestion de configuration - miniwebpage T. Jgenti

Transcription

Conservatoire National des Arts et Métiers, Paris
Informatique, Réseaux, Systèmes et Multimédia
Le point sur
la gestion de configuration
Mémoire d’examen probatoire, mai 2005
Thomas JGENTI
Soutenance du Lundi 30 mai 2005
Jury
Président : M. PRINTZ – Professeur ;
Membres :
Le point sur la gestion de configuration
Table de matières
Introduction............................................................................................................................... - 2 Définition ................................................................................................................................... - 3 Partie I – Problématique.......................................................................................................... - 4 Cycle de vie du logiciel..................................................................................................... - 4 Problèmes liés à la gestion de configuration................................................................ - 4 Partie II - Concepts et principes ............................................................................................ - 8 Contrôle du partage de données..................................................................................... - 9 Contrôle de version ......................................................................................................... - 13 Contrôle de configuration .............................................................................................. - 15 Contrôle de processus ..................................................................................................... - 16 Partie III - Outils logiciels ..................................................................................................... - 18 Marché des logiciels spécialisés .................................................................................... - 18 Outils commerciaux......................................................................................................... - 18 Outils du domaine public................................................................................................ - 22 Synthèse comparative ..................................................................................................... - 26 Partie IV - Mise en œuvre ..................................................................................................... - 27 Standards et recommandations..................................................................................... - 27 Bonnes pratiques.............................................................................................................. - 27 Exemple de mise en œuvre............................................................................................ - 28 Conclusion................................................................................................................................ - 30 Bibliographie ........................................................................................................................... - 31 Glossaire................................................................................................................................... - 32 Annexe I – Comparatif des logiciels dédiés à la GCL ....................................................... - 33 Annexe II – Liste de logiciels dédiés à la GCL.................................................................... - 34 -
-1-
Introduction
La gestion de configuration n’est pas un domaine nouveau, il existe depuis les débuts de
l’informatique. Pourtant c’est une discipline trop souvent négligée ou mal connue. Destinée à
améliorer l’efficacité et la qualité, en particulier au sein des projets logiciels, elle est parfois mise
au second plan derrière les méthodes de gestion traditionnelles et les considérations purement
techniques. Pourtant la gestion de configuration est le pont qui lie la gestion de projet avec les
biens essentiels du projet – ses données. Loin d’être un fardeau, elle permet de garder la maîtrise
et la trace de tous les changements survenus ou à venir durant tout le cycle de vie du projet.
L’objectif de ce document est d’expliquer l’intérêt de cette gestion, de décrire ses principes, de
comparer les solutions existantes et de montrer sa mise en œuvre.
La première partie de ce document démontre l’intérêt de la gestion de configuration en étudiant
les problèmes qu’elle permet de résoudre. En prenant le cas particulier de la gestion de
configuration logicielle, des exemples concrets montrent que chaque projet, tôt ou tard, est amené
à gérer ces problèmes, tels que les modifications simultanées, les développements multi plateforme, duplications de données et la double maintenance.
La seconde partie introduit les notions propres à la gestion de configuration logicielle et définit
ses aspects essentiels. Elle illustre les principes de gestion de ces différents aspects, tels que le
contrôle de versions, le contrôle de configurations, le partage de données et le contrôle de
processus.
La troisième partie décrit et compare les outils logiciels dédiés à la gestion de configuration.
L’étude porte sur les outils du commerce, tels que ClearCase ou Telelogic Synergy et les outils
libres, comme CVS, Ant ou encore Bugzilla.
Enfin, la dernière partie présente les recommandations issues des standards industriels, les bonnes
pratiques et un exemple synthétique de la mise en œuvre de la gestion de configuration et de ses
outils.
-2-
Définition
Tous les acteurs du domaine informatique ont leur propre définition de la gestion de
configuration, qui n’est jamais réellement la même. En voici une donnée par l’auteur de ce
document :
La gestion de configuration est un ensemble de procédés qui permettent le contrôle de
tout changement passé, présent ou à venir dans un système logiciel ou matériel.
Cette définition très générale mérite quelques précisions car la gestion de configuration peut être
vue sous plusieurs aspects. Ce document évoquera plus particulièrement la gestion de
configuration logicielle (Software Configuration Management ou SCM en anglais) qu’il est
possible de définir comme suit :
La gestion de configuration, nommée GCL dans le cadre du développement "Logiciel",
permet de connaître à tout moment l'état de l'ensemble des composants d'un projet en
contrôlant les évolutions du logiciel durant la totalité de son cycle de vie.
Cette définition à la fois concise et juste est une citation du site Internet dicodunet.com. Plus loin
dans ce document le terme de gestion de configuration logicielle sera parfois présent sous forme
abrégée : GCL. Bien que la gestion de configuration dépasse le seul cadre du développement
logiciel, ce dernier permet de faire une analyse complète de ces aspects. Parmi les autres
domaines d’application on peut citer la gestion de contenus (Content Management) ou encore
l’élaboration de sites Internet, qui tend à rejoindre le développement logiciel.
Enfin, il est possible de définir la GCL par ses principaux objectifs :
•
•
•
•
•
Contrôle des versions de données ;
Partage et sécurité des données ;
Contrôle des configurations des distributions de produits ;
Traçabilité des problèmes et des modifications ;
Gestion de tous ces points au sein d’un processus ;
-3-
Partie I – Problématique
Cycle de vie du logiciel
L’objectif de cette partie est de démonter l’intérêt de la gestion de configuration en partant des
problèmes qu’elle permet de résoudre. En effet, dans le cycle de vie d’un projet logiciel les
premières phases sont loin des préoccupations de configurations ou de versions et concernent les
spécifications du produit, la conception, les choix technologiques et l’organisation des ressources
humaines. Figure 1
Recette
Spécifications
des besoins
Conception
générale
Tests
d’intégration
Conception
détaillée
Codage
Tests des
modules
Tests unitaires
Figure 1 – Cycle de vie itératif du développement logiciel. Les étapes les plus concernées par la GCL sont en
jaune
En pratique la gestion de configuration touche surtout les développeurs, plutôt que les
responsables. Si les premiers sont conscients d’un besoin latent de cette gestion, en règle générale
ils favorisent néanmoins les aspects de conception et de codage au détriment des taches
organisationnelles. Par conséquent, le rôle du responsable du projet est de mettre en place une
politique de gestion de configuration avec les méthodes et les outils appropriés.
La nécessité de la gestion de configuration se dévoile surtout dans les phases du milieu et de fin
du cycle de vie logiciel et c’est pour cette raison elle se trouve souvent négligée par les décideurs.
Pourtant, chaque projet logiciel, tôt ou tard, est amené à cette gestion, qu’elle soit planifiée ou
non. Les chapitres suivants identifient les problèmes courants qui nécessitent cette gestion et ainsi
démontrent son importance.
Problèmes liés à la gestion de configuration
Afin de mieux comprendre l’enjeu de la GCL il faut imaginer un projet contre-exemple :
-4-
•
•
•
•
Où les fichiers se trouvent à un seul endroit et peuvent être accédés par tout le monde ;
Qui n’est jamais sauvegardé et où tout changement est définitif ;
Qui ne garde pas la trace des changements apportés et n’identifie pas leurs auteurs ;
Qui ne possède pas de moyen de distinguer les versions du logiciel et leurs différences ;
Un bon nombre de projets n’ayant pas planifié une gestion de configuration adéquate débute dans
cet état et se heurte à des problèmes obligeant de mettre en place des solutions plus ou moins
efficaces et à retarder le projet. Parmi ces aspects on peut citer :
•
•
•
•
•
Partage et modifications simultanées de données par plusieurs intervenants ;
Double maintenance des ramifications de données ;
Besoin de retour à un état antérieur stable du logiciel suite à une erreur ;
Besoin de garder un historique des développements ;
Contrôle et validation des ajouts et des corrections ;
Les quatre premiers points sont des aspects bien connus et constituent ce que l’on pourrait
appeler la gestion de configuration « traditionnelle ». Quant au dernier, il s’inscrit dans une
logique orientée vers la gestion de processus ou de tâches qui complète la vision traditionnelle de
la GCL et constitue la gestion de configuration au sens actuel de ce terme.
Les paragraphes suivants détaillent ces problèmes que l’on rencontre dans tous les projets
logiciels.
Partage et modifications simultanées
Le partage de données et la gestion des accès concurrents sont des problèmes bien connus dans
les domaines tels que les bases de données ou les réseaux. Il en est de même dans le domaine du
développement logiciel, où l’on parle plutôt de développement parallèle ou asynchrone.
En effet rares sont les projets industriels ayant un seul développeur et dans l’immense majorité
des cas plusieurs développeurs travaillent sur le même code source. Bien que leur travail est
défini à l’avance en tant que tâches distinctes, les développeurs sont souvent amenés à intervenir
sur les mêmes fichiers que leurs collègues. Ainsi des modifications simultanées peuvent-elles
survenir sur deux copies du même fichier et il deviendra nécessaire de les fusionner lors de leur
intégration dans le projet. Figure 2
Modification 1
Original
Résultat
Fusion
Modification 2
-5-
Figure 2 – Exemple de fusion de modifications simultanées
Pour cet aspect, le rôle d’un système de gestion approprié est avant tout de préserver la cohérence
des données et de vérifier si un changement concurrent a eu lieu. La vérification et le cas échéant
la fusion des cas simples peuvent être automatisées. Si une fusion automatique n’est pas possible,
le système doit signaler un conflit qui devra être réglé manuellement. Les techniques employées
par les systèmes de GCL sont détaillées dans la section Techniques de fusion des
changements concurrents.
Double maintenance
Cette fois le problème est inverse : il ne s’agit plus d’apporter deux modifications différentes à la
même donnée, mais d’apporter la même modification à plusieurs copies de la donnée.
Les raisons de multiplier les copies des données du projet sont nombreuses :
• Création d’une copie du projet correspondant à une version ;
• Développements multi plate-forme avec des configurations spécifiques ;
• Création d’une copie en vue de modifications spécifiques ne devant pas perturber le projet
principal, etc.
Ainsi chaque copie est faite en raison d’une spécificité et constitue une configuration différente.
Pourtant si l’on considère l’ensemble des données dupliquées, ces copies sont fortement
redondantes.
V1.0.1
V1.0
figée
Double
correction !
Copie
V1.0
V1.1
Dév.
V1.1.1
Dév.
Figure 3 – Double maintenance des ramifications
Exemple :
Une version du logiciel vient d’être terminée et une copie du projet est faite afin de figer cette
version dans l’état. Les développements d’une prochaine version sont en cours lorsqu’un grave
problème de fonctionnement vient d’être signalé par les utilisateurs de la version livrée. Une
correction doit être apportée à la version qui venait d’être figée, mais aussi à la version en
préparation ! Figure 3
Afin d’éviter la perte de temps et tout risque d’erreur induits par la double maintenance, un
système de GCL doit gérer les ramifications, que l’on appelle des branches.
Dans le cas de développement multi plate-forme le problème est similaire, car même si le code
source est entièrement portable, la construction du fichier binaire exécutable est spécifique à
chaque plate-forme. Ces spécificités sont aussi des configurations dont il faut gérer les
redondances. Figure 4
-6-
Debug
Debug
WinXP
Debug
WinXP
WinXP
Source
Debug
SunOS
Produit
Linux
Produit
WinXP
Produit
SunOS
Figure 4 – Configurations différentes pour le même code source, selon les plates-formes et les paramètres.
Historique des versions
Nous venons de voir le problème que pose une copie des données afin de protéger l’état d’une
version. Pourtant l’intérêt d’une telle copie est de pouvoir revenir à un état stable. Il n’est pas rare
dans un projet de devoir revenir à un état antérieur au développement courant, que ce soit pour
intervenir sur une version précédente, mais aussi pour défaire un développement qui s’est avéré
erroné et bloquant. Aussi, une simple copie figée d’une version antérieure ne suffit pas dans ce
dernier cas. Idéalement il faut pouvoir défaire tous les changements apportés un par un et pour ce
faire il est nécessaire d’archiver chaque modification et pourvoir retracer ces modification grâce à
un historique explicite.
En résumé, dans ce cas les besoins sont :
• Archiver les versions majeures du logiciel ;
• Archiver toutes les versions des sources intermédiaires, chaque version étant un
changement dû à une fonctionnalité ;
• Garder un historique de ces versions et pouvoir retracer tous les changements ;
Souvent le terme de gestion de configuration est confondu avec celui de gestion de versions, car
il s’agit d’un principe essentiel. Pourtant la GCL ne doit pas être réduite à ce seul aspect.
Contrôle et validation des modifications
Si la gestion de configuration aide à résoudre certains problèmes courants du développement
logiciel, il s’agit également d’une méthode de travail qui s’inscrit pleinement dans le cycle de vie
d’un projet. Ainsi un système de GCL peut non seulement archiver les modifications, mais
également permettre leur planification et contrôler le processus entier de développement.
L’organisation et la planification du projet doivent concorder avec les modifications apportées.
Le responsable du projet doit pouvoir les affecter aux développeurs suivant une priorité, contrôler
leur exécution et les valider.
-7-
Partie II - Concepts et principes
Avant de détailler les différentes techniques utilisées dans la gestion de configuration, il faut
connaître certaines notions et termes consacrés à ce domaine :
Anglais :
Français :
Description :
Workspace
Espace de
travail
Espace local où le développeur travaille sur une copie privée
du projet. On parle également de « espace de travail privé » car
il existe autant d’espaces que de développeurs.
Repository
Dépôt
Espace sécurisé et commun au projet, où sont archivées toutes
les données gérées par le système de gestion de configuration.
Le terme anglais repository est le plus souvent utilisé.
Ligne de développement représente les états successifs du
Ligne de
Line of
development ; développement projet dans le temps.
Codeline
Branch
Branche
Les branches sont les ramifications des lignes de
développement du projet. Exemple : branche principale de
développement et branche test d’une version.
Check-out ;
Export
Export
Il s’agit d’exporter les données du projet depuis le repository
vers un espace de travail. Le plus souvent ce terme désigne la
création de l’espace de travail privé qui est ensuite mis à jour.
Update
Mise à jour
Mise à jour de l’espace de travail privé avec le repository. Il
s’agit de récupérer les modifications apportées par les autres
développeurs.
Check-in ;
Commit ;
Import
Import
Import des modifications apportées localement dans un espace
de travail dans le repository, par opposition à update. Le terme
anglais commit est généralement utilisé.
Merge
Fusion
Fusion de la donnée de référence contenue dans le repository
avec une modification locale en vue d’un commit.
Conflict
Conflit
Conflit engendré par l’impossibilité d’une fusion automatique.
Les conflits doivent être résolus avant d’effectuer un commit.
Version ;
Revision
Version
Le terme version ou révision est souvent appliqué à chaque
entité individuelle du repository et non seulement au projet
dans son ensemble.
-8-
Contrôle du partage de données
Principe du Repository
La notion de dépôt, plus couramment appelé repository, est essentielle dans un système de
gestion de configuration, car il s’agit de l’emplacement où le système archive toutes les données
du projet. Lors de la mise en place du système de GCL le repository est initialisé à partir d’une
version initiale du projet importée depuis un espace de travail. Les données du repository peuvent
ensuite être exportées vers les espaces de travail d’autres développeurs. Ainsi se met en place un
partage de données du projet avec le dépôt commun.
Architectures de partage de données
Le repository se trouve de manière générale sur un disque ou un serveur ayant un accès sécurisé
et doit être sauvegardé régulièrement. Le partage doit être possible via le réseau afin de permettre
aux personnes éloignées géographiquement de travailler sur le même projet.
Le repository peut être centralisé ou distribué sur plusieurs serveurs. Dans ce dernier cas le
système doit assurer la synchronisation de toutes les copies du repository. L’avantage des dépôts
distribués est d’éviter le risque de perte de données grâce à la duplication, mais l’inconvénient est
d’exiger un système plus complexe à concevoir.
Serveur
Serveur
Local
repository 0
B
workspace 1
C
Réseau
repository
Réseau
Réseau
repository 1
repository 2
repository 3
workspace 2
workspace 3
workspace 1
repository 2
repository 3
workspace 2
workspace 3
local
Local
A
repository 1
workspace 2
workspace 3
workspace 1
Figure 5 – Exemple de topologies mises en œuvre pour le partage des données.
La Figure 5 illustre trois stratégies de mise en œuvre de repository partagé :
A. repository centralisé avec l’architecture client/serveur. C’est une technique classique que
l’on retrouve dans la plupart des systèmes, exemple : système de gestion de version open
source CVS ;
B. repository distribué avec l’architecture client/serveur ;
C. repository distribué avec l’architecture peer-to-peer (P2P), architecture plus récemment
adoptée par quelques systèmes open source, tels que Monotone ou Darcs ;
-9-
Prise en compte des changements
Pour qu’un changement fait dans un espace de travail local soit pris en compte par le projet, il
doit être importé dans le repository. Idéalement les imports et les mises à jour doivent rendre la
fusion des modifications transparente et ne demander une fusion manuelle que dans des cas de
conflits. Il ne s’agit pas uniquement d’un confort d’utilisation, mais d’une garantie de la
préservation des changements. En effet avec certains systèmes l’utilisateur doit mettre à jour son
espace de travail avant d’importer ses changements, faute de quoi les modifications contenues
dans les repository peuvent être écrasées ! Par conséquent, il est important de connaître le
comportement exact d’un outil de gestion de changements.
Lors d’une synchronisation de l’espace de travail avec la base commune, le système de gestion
compare les fichiers locaux avec leurs versions de référence contenues dans le repository. Les
quatre cas suivants peuvent alors survenir :
Résultat de comparaison :
Action à entreprendre :
•
Les deux fichiers sont
identiques
Aucune
Aucun changement à importer.
•
Le fichier du repository est une
version plus récente que le
fichier local
Mise à jour
Le fichier local peut être mis à jour avec les
modifications contenues dans le repository.
•
Le fichier local est plus récent
que celui du repository
Import
Les modifications locales doivent être importées.
•
Le fichier local a été modifié,
mais celui du repository est une
version plus récente.
Mise à jour (selon les
outils)
Fusion
Import
Avec certains outils, tels que CVS, le fichier local
doit d’abord être mis à jour, puis les
modifications contenues dans les deux fichiers
doivent être fusionnées avant d’être réimportées
dans le repository.
D’autres outils importent et fusionnent les
changements de manière transparente et ne
signalent que des conflits survenus.
Figure 6 illustre ces différents cas de synchronisation avec le repository.
A noter que le système doit gérer les accès concurrents en lecture et en écriture et bloquer l’accès
à une ressource durant sa mise à jour. Il doit également permettre un retour en arrière en cas
d’échec d’une mise à jour du repository suite à un import.
- 10 -
Local
=
Repository
Local
=
Local
Mise à jour
Repository
Repository
Local
=
Import
Repository
Repository
Local
=
Import
Fusion
Repository
Repository
Local
Synchronisation :
Mise à jour
Fusion
Import
Repository
Figure 6 - Prise en compte des changements entre l'espace de travail local et le repository
Techniques de fusion des changements concurrents
Le système de gestion doit identifier les différences entre deux fichiers afin de pouvoir les
comparer et les fusionner. Il existe plusieurs algorithmes de différentiation de fichiers texte (la
fusion des fichiers binaires n’a souvent pas de sens). L’un des algorithmes les plus répandus est
celui de la commande UNIX diff qui compare deux fichiers ligne par ligne et donne les
indications sur les lignes qui diffèrent. Une variante de cet algorithme est diff3, capable de
différencier trois fichiers : fichier du repository avant changement, fichier du repository modifié
et le fichier local. La fusion utilisant ces trois versions de fichiers est appelée « 3-way merge ».
L’avantage de 3-way merge est de prendre en compte la version de référence avant changement,
ce qui permet de vérifier si une même ligne ou un bloc de lignes a été modifié des deux côtés,
dans quel cas il s’agit d’un conflit, ou bien si une fusion automatique est possible.
La fusion automatique n’est sure que lorsque les deux modifications concernent deux parties
complètement différentes du fichier, or comment un système automatisé peut-il détecter cela ?
Les algorithmes utilisent les techniques suivantes, de la plus prudente à la plus optimiste :
• Comparaison ligne par ligne et détection de blocs de lignes différents (diff, diff3) ;
• Comparaison de lignes ou de caractères avec une analyse sémantique du fichier ;
• Comparaison caractère par caractère et détection de blocs de caractères différents
(kdiff3) ;
- 11 -
Bien que la dernière technique soit assez simple et permet une fusion automatique plus souple,
celle-ci peut générer un résultat sémantiquement absurde et devra supporter une correction
manuelle.
Version de
référence
Modification 1
Modifications 2
Le résultat de fusion automatique :
incohérence sémantique !!!
Figure 7 - Pièges de la fusion automatique (l’illustration utilise le logiciel kdiff3)
La figure ci-dessus illustre un piège de la fusion automatique « optimiste » : bien que celle-ci
semble réussie, l’algorithme n’a pas été capable de détecter l’appel redondant à la méthode
drawCat, ce que les développeurs n’envisageaient visiblement pas. De plus, l’énumération de
switch/case est devenue incohérente !
L’analyse sémantique des fichiers demande au système de connaître les spécificités des langages
de programmation, ce qui est très difficilement envisageable. De ce fait l’approche de diff3, avec
des améliorations parfois apportées, est utilisée dans la plupart des systèmes actuels. Bien que les
conflits non résolus automatiquement soient plus nombreux dans ce cas, le contrôle humain des
conflits assure la cohérence finale des données. Figure 8
Version de
référence
Modifications 1
Modifications 2
La fusion automatique n’est pas possible :
Conflit de fusion
Figure 8 - Exemple de conflit ne pouvant être résolu automatiquement
- 12 -
Contrôle de version
Les données contenues dans un repository ne sont pas une simple copie des données de l’espace
de travail. Il s’agit des archives possédant les informations sur chaque version permettant de
recréer dans un espace de travail une image exacte du projet d’une version donnée. Le contrôle de
version peut intervenir à plusieurs niveaux :
• Fichiers ;
• Arborescences ;
• Changements de nom de fichiers ou de répertoires ;
• Branches ;
Versions de fichiers
L’archivage des versions de fichiers peut être réalisé de manières suivantes :
• Copie intégrale du fichier pour chaque version ;
• Incrémentale : où soit la première, soit la dernière version est archivée plus les différences
(deltas) dues aux modifications successives, Figure 9 ;
L’intérêt de la première méthode est dans sa simplicité, mais la méthode incrémentale est bien
plus performante en termes de taille d’archive obtenue. Cette dernière est couramment utilisée
dans la plupart des systèmes existants afin de gérer les fichiers de type texte, car la difficulté qui
réside dans cette méthode est de détecter les différences entre deux versions de fichiers binaires.
Ainsi certains systèmes ne peuvent gérer efficacement les versions des fichiers binaires, ou bien
archivent des copies intégrales de ces fichiers, ce qui tend à augmenter la taille du repository à
chaque commit de tels fichiers.
Archivage intégral
Archivage incrémental
Version initiale 1.0
b =
b++
a =
c++
c = 1 ;
;
b + c ;
;
b =
b++
a =
c++
c = 1 ;
;
b + c ;
;
Version 1.1
Ajout à la ligne 4
b =
b++
a =
b =
c++
c = 1 ;
;
b + c ;
b + a ;
;
Ligne4
<<
b = b + a ;
->>
Version 1.2
Suppression à la
ligne 2
b =
a =
b =
c++
c = 1 ;
b + c ;
b + a ;
;
Ligne2
<<
-b++ ;
>>
Figure 9 - Exemple de méthodes d'archivage de versions : intégral et incrémental. La syntaxe des incréments
est similaire à celle de la commande UNIX diff.
- 13 -
Par souci de clarté, l’exemple de la figure ci-dessus montre l’archivage incrémental à partir de la
version initiale. Cependant afin d’améliorer la performance d’accès aux données, les systèmes
privilégient souvent d’archiver la dernière version dans son intégralité et de garder les différences
en tant que décréments.
Versions des tâches
Certains systèmes, orientés vers la gestion de tâches, permettent d’archiver chaque changement
apporté de manière atomique et indépendante. Ainsi il est possible non seulement de revenir vers
une version dans le temps, mais aussi de retirer un changement particulier sans affecter les
changements ultérieurs indépendants. En cas d’interdépendances des changements, toutes les
taches dépendantes seront également retirées. Le système peut vérifier les dépendances grâce à
une arborescence de changements, appelée également la théorie de patches.
Gestion des arborescences et des changements de noms
Afin que la configuration d’une version donnée, récupérée depuis le repository, soit fidèle à son
état original, il est indispensable que le système de gestion de versions puisse conserver la trace
de tous les changements intervenus dans la structure de l’arborescence des fichiers et restituer
l’arborescence exacte correspondant à cette version. Ces changements ne concernent pas
uniquement des ajouts ou des suppressions, mais aussi les changements des noms de répertoires
ou de fichiers. Un bon système doit être capable de garder la trace d’une même entité au cours de
toute la ligne du développement, même si celle-ci avait été renommée entre deux versions.
Branches
Les branches sont des ramifications de la ligne de développement principale (tronc principal) qui
sont le plus souvent liées à la livraison d’une version majeure du logiciel. Les méthodes
d’archivage des branches sont identiques à celles des versions de fichiers ou d’arborescences. A
noter que le système doit également permettre et gérer la fusion d’une branche avec le tronc
principal. Figure 10
Branche
TEST
V1.0
TEST
V1.0.1
TEST
Fusion
Corrections
Ligne de
dév.
V1.0
V1.1
V1.1.1
Figure 10 – Exemple de ramification et de fusion de branche
- 14 -
Contrôle de configuration
Les configurations qu’un système est amené à gérer ne sont pas uniquement les versions dans une
ligne de développement temporelle, mais également toutes les configurations du projet qui
peuvent exister en parallèle dans une même version et une même branche.
Exemple : configurations liées au plates-formes différentes, ou bien configuration de déboguage
et configuration de livraison (release).
Les buts d’un système de contrôle de configuration sont :
• Contrôler les dépendances entre les données du projet ;
• Contrôler les dépendances avec l’environnement de la plate-forme de développement ;
• Contrôler les paramètres et le déroulement de la génération automatisée des données :
compilation des fichiers sources, génération de la documentation etc. ;
• Contrôler les paramètres de l’édition des liens avec les données extérieures au projet ;
Dans la majeure partie des cas les outils qui gèrent ces configurations sont spécifiques et
différents des gestionnaires de versions. Ainsi, en particulier pour les systèmes UNIX, l’outil
Make est souvent utilisé, avec des variantes et améliorations telles que gmake (GNU Make),
imake ou encore configure.
Construction d’exécutables multi plate-forme
Source
bl
.cpp
Configurations :
Makefiles, scripts,
build.xml, .dsp etc.
Plates-formes :
SunOS
Linux
Win32
Figure 11 –Configurations d'un projet multi plate-forme
Le principe de fonctionnement de Make illustre bien la technique de construction d’exécutables.
Ce principe est basé sur un ensemble de règles qui permettent la compilation, l’édition des liens
et d’autres étapes nécessaires à la construction de l’exécutable à partir d’un code source. Ces
règles sont contenues dans les fichiers appelés Makefiles. Il existe plusieurs manières possibles
afin de construire des programmes exécutables sur des plates-formes différentes :
• Placer les paramètres correspondant à ces plates-formes dans des règles séparées du
même Makefile ;
• Placer ces paramètres dans des Makefiles séparés (Figure 11) ;
- 15 -
•
Créer une Makefile avec des règles génériques et utiliser des fichiers de configuration
séparés ;
La première solution a l’inconvénient de devenir peu compréhensible et inutilisable avec un
projet de taille importante. La dernière solution a l’avantage de mieux limiter le problème de
double maintenance que la seconde, mais peut être plus complexe à mettre en place.
Environnements de développement intégrés
Les environnements de développement intégrés (Integrated Development Environment ou IDE en
anglais), tels que l’environnement open source Eclipse d’IBM (eclipse.org) ou encore Microsoft
Visual Studio, proposent également des outils de gestion de ce type de configurations. Leur
principe de fonctionnement interne qui reste similaire, sinon identique, à celui des Makefiles.
Paramètres de la
configuration Debug
Configurations :
Debug et Release
Figure 12 – Exemple d’interface de paramètres du projet de Microsoft Visual C++ 6
L’avantage de ces outils est leur convivialité grâce aux interfaces utilisateur graphiques (Figure
12) qui facilitent le travail des développeurs et limitent le risque d’erreurs. Cependant, comme
dans l’exemple de Microsoft Visual Studio, ces outils sont parfois restreints à une seule plateforme de développement.
Contrôle de processus
Planification et gestion de processus
L’approche de gestion de processus tend à concilier la planification du projet avec la gestion de
versions et de configurations. Il s’agit de planifier les modifications à apporter au projet, à les
identifier clairement en tant que taches du projet et à les assigner aux développeurs concernés.
Cette approche rend la gestion de versions plus efficace est plus claire, car elle évite aux
membres du projet d’apporter des changements non structurés ou désordonnés.
Les points importants de la gestion de processus sont :
• Définition et assignation des taches (groupes de modifications) ;
• Différentiation des changements planifiés et des requêtes de modification ;
• Classement et validation des requêtes de modification ;
• Vérification et validation des changements apportés ;
- 16 -
•
•
•
Planification et validation des versions majeures (releases) ;
Validation des versions de patches correctifs ;
Propagation des corrections entre les branches du projet ;
Traçabilité de requêtes de modifications
Les requêtes de modification se distinguent des taches planifiées, car elles doivent d’abord être
traitées : étudiées puis validées ou non. Il s’agit le plus souvent des requêtes de maintenance qui
proviennent des utilisateurs ne faisant pas partie du projet. A ce titre elles nécessitent une gestion
spécialisée, car constituent des taches parallèles au développement. Cette gestion doit offrir une
traçabilité des requêtes aux responsables du projet, mais également aux initiateurs, voire à tous
les utilisateurs.
La prise en compte des requêtes de maintenance intervient essentiellement dès les premiers tests
du produit et ensuite durant tout son cycle de vie. Pour chaque requête l’on doit garder la trace
des paramètres suivants :
• La version du produit concernée ;
• La configuration concernée (plate-forme) ;
• Les fonctionnalités concernées ;
• La priorité de la modification corrective ;
• Le membré du projet chargé d’effectuer la modification ;
• Statut de la requête : confirmée, assignée, en cours, résolue, validée (fermée). Figure 13 ;
Figure 13 – Cycle de vie d’une requête de maintenance.
- 17 -
Partie III - Outils logiciels
Marché des logiciels spécialisés
L’étendue des solutions logicielles existantes sur le marché actuel est importante. Il n’existe pas
moins de huit éditeurs de logiciels proposant des outils commerciaux et une multitude de projets
de logiciels libres, dont le très répandu CVS. Si les premiers tendent à fournir des solutions
complètes pour des projets de grande envergure, les seconds offrent des outils efficaces et
accessibles, mais souvent moins complets ou bien dans des phases de développement
prématurées (versions bêta).
Le marché professionnel subit d’importants changements liés aux opérations de rachats ou de
fusions des sociétés. C’est ainsi que le produit Rational ClearCase est édité aujourd’hui par la
société IBM, que le logiciel PVCS de la société Merant est devenu ChangeMan de la société
Serena suite à un rachat de même que le logiciel Continuus/CM est devenu Synergy de la société
Telelogic.
Parmi les projets de logiciels libres, également appelés open-source, CVS reste en tête depuis
plus de dix ans d’existence, mais il existe au moins une dizaine d’alternatives sérieuses apparues
plus récemment. Aujourd’hui le site Internet des projets open-source sourceforge.net recense près
de 500 projets qui touchent de près ou de loin à la gestion de configuration !
Outils commerciaux
Les paragraphes suivants présentent les outils commercialisés par quelques acteurs majeurs du
domaine de la GCL. Leur étude se base sur des comparatifs et les caractéristiques éditeur.
IBM Rational ClearCase
Le produit ClearCase, d’abord commercialisé par la société Atria Software, puis par Rational
Software racheté en 2003 par IBM se positionne comme une solution de gestion de configuration
complète depuis plus de dix ans.
Avantages :
• Contrôle de version avec gestion complète du
renommage et des arborescences ;
• Contrôle de configuration intégrant la
construction des exécutables ;
• Multi plate-forme ;
• Produit mature, existe depuis plus de dix ans ;
• Interface graphique ;
• Intégration dans les IDE : Microsoft .NET, IBM
WebSphere et Eclipse (initialement projet opensource d’IBM);
Inconvénients :
• Exige d’importantes ressources matérielles et
une administration accrue ;
• Fonctionnalité de travail sur plusieurs sites
géographiques est une option : ClearCase
MultiSite ;
• Exige ClearQuest pour être une solution de
GCL réellement complète (gestion d’activité et
de traçabilité) ;
• Prix de la solution complète ;
Ce logiciel propose le contrôle de version et de configuration avec une approche traditionnelle
(check-in/check-out). Afin de disposer de fonctionnalités de traçabilité des requêtes et de contrôle
de processus, ClearCase doit être complété par un autre outil de la gamme : ClearQuest.
- 18 -
ClearCase est basé sur le modèle client/serveur avec un repository unique fonctionnant avec une
base de données sur un serveur dédié. Enfin, il est proposé sur la majorité des systèmes Unix
(AIX, HP-UX, IRIX, Solaris), Linux et Windows.
Serena ChangeMan
Anciennement connu sous le nom PVCS de la société Intersolv, puis de la société Merant,
rachetée en 2004 par Serena Software, ChangeMan est une gamme de logiciels dédiés à la GCL.
Les outils de la gamme : Version Manager (gestion de versions), TeamTrack (traçabilité des
changements) et Builder (gestion de configuration) constituent une offre similaire à ClearCase
d’IBM. Mais à l’instar de ce dernier, l’offre commerciale de Serena propose des options pour
obtenir une solution complète. Ainsi le produit Dimensions est indispensable pour bénéficier
d’une approche de gestion de processus.
Techniquement il s’agit d’une architecture client/serveur avec un repository sécurisé sur un
serveur dédié. Existe pour la plupart des plates-formes UNIX, Linux et Windows (dont les
systèmes 64bits). Le repository peut être distribué avec l’intégration de ChangeMan/DS.
Avantages :
• Contrôle de version complet (renommage,
arborescences, fusion améliorée) grâce au
module Version Manager;
construction des exécutables avec Builder;
• Traçabilité des requêtes avec le module
TeamTracker ;
• Technologie mature ;
• Intégration dans les IDE : Microsoft .NET et
Eclipse ;
Inconvénients :
• Solution lourde visant des projets d’envergure,
qui exige d’importantes ressources matérielles ;
• Offre commerciale très complexe et fragmentée,
obligeant d’acquérir plusieurs modules séparés
afin d’obtenir une solution complète coûteuse ;
• Exige un produit complémentaire pour un
déploiement distribué (ChangeMan/DS) ;
• Exige un produit complémentaire pour la
gestion des processus (Dimensions) ;
Telelogic Synergy
Synergy est également une gamme d’outils destinée à la gestion de configuration, anciennement
connue sous le nom de Continuus/CM de la société Continuus, rachetée en 2000 par Telelogic.
Contrairement à ClearCase, Synergy utilise directement une approche orientée gestion de
processus. Chaque changement est associé à une tache assignée à un développeur. A noter que
Synergy propose une intégration avec Microsoft Project.
L’architecture est similaire à ChangeMan avec un repository contenu dans une base de donnée et
l’approche client/serveur. Tout comme pour ChangeMan/DS, le repository peut être distribué
avec l’option Synergy/Distributed CM.
- 19 -
Avantages :
• Approche orientée gestion de tache et gestion de
processus ;
• Contrôle de version complet ;
construction des exécutables avec le module
Synergy/CM Object Make ;
• Technologie mature, plus de dix ans
d’existence ;
• Intégration avec : Microsoft .NET, Eclipse,
Microsoft Project, Matlab (!) ;
Inconvénients :
• Offre commerciale fragmentée, avec nombreux
modules en option ;
Microsoft Visual SourceSafe
Visual SourceSafe, ou VSS, est un complément de l’IDE de Microsoft : Visual Studio et .NET. A
ce titre il est librement accessible aux développeurs utilisant cet environnement. Il s’agit d’un
système de gestion de version et de changements ayant des fonctionnalités minimales, adapté aux
projets relativement peu importants. VSS est assez répandu grâce à son disponibilité et facilité
d’intégration et malgré ces limitations.
Bien entendu ce système n’existe que sur la plate-forme Windows et utilise un repository avec
une base de données.
Avantages :
• Facile installation et intégration avec Visual
Studio ;
• Disponible librement aux utilisateurs de Visual
Studio ou MSDN ;
• Intégration avec : Microsoft .NET et Eclipse
(plug-in optionnel) ;
Inconvénients :
• Unique plate-forme : Windows ;
• Gestion de changements concurrents simpliste
nécessitant une rigueur dans l’utilisation ;
• Gestion de version limitée pour les branches ;
• Gestion de configuration est laissée à l’IDE ;
• Aucune approche de gestion des taches ;
Perforce SCM System
Perforce est un système de gestion de versions simple, qui fait l’accent sur la performance et le
mode de fonctionnement distribué avec un système de proxy appelé P4P. Fonctionnant sur le
modèle client/serveur, il dispose d’un repository central sur le serveur appelé P4D contenant une
base de donnée dédiée. Le serveur communique avec les clients grâce à TCP/IP et peut être
installé sur la plupart des plates-formes Windows, Unix, MacOS et Linux. Le client existe en
version ligne de commande et avec une interface graphique, appelé P4V.
Perforce utilise l’approche traditionnelle de gestion de configurations, mais dispose d’un système
de traçabilité des problèmes intégré et offre l’intégration avec des outils tiers tels que Bugzilla.
Avantages :
• Fonctionnement distribué avec des caches de
Inconvénients :
• Aucune approche de gestion des taches ;
- 20 -
repository ;
Robuste et performant ;
Interface graphique P4V ;
Multi plate-forme ;
Intégration avec IDE : Microsoft .NET, Borland
JBuilder ;
• Intégration avec des outils tiers tels que :
Bugzilla, Araxis Merge etc. ;
• Prix de licence non prohibitif ;
•
•
•
•
• Gestion de changements concurrents simpliste
nécessitant une rigueur dans l’utilisation ;
BitKeeper PRO
BitKeeper de la société américaine BitMover, fondée en 1998, est un outil de gestion de
configuration axé, comme la plupart, sur la gestion de versions. Sa particularité réside dans son
architecture complètement distribuée peer-to-peer. Les repository compressés sont répliqués sur
chaque client correspondant à un espace de travail et qui est également un serveur pour tous les
autres clients. A travers cette technique BitKeeper se présente comme un logiciel plus sûr, car
exempt de risque de panne du serveur central – il n’en possède pas !
Bien que BitKeeper soit un outil commercial, il est bien connu dans le domaine des logiciels
libres. En effet, la société BitMover, dont le fondateur Larry McVoy est issu du monde Linux,
rendait son outil disponible pour les projets open-source jusqu’à avril 2005. Sa réputation est
d’être un outil fiable et performant, bien que moins complet que les solutions telles que Telelogic
Synergy : les fonctionnalités de BitKeeper dans le domaine du contrôle de versions sont plus
fournies, mais l’aspect de la gestion de processus est négligé.
BitKeeper est disponible sur une large variété de plates-formes Linux, Unix, Windows et MacOS.
Avantages :
• Fonctionnement totalement distribué avec
réplication de repository et P2P ;
• Robuste et performant ;
• Très largement multi plate-forme ;
• Fonctionnalités avancées de contrôle de
version : branches dynamiques, fusion des
changements améliorée, atomicité des commits ;
• Traçabilité de requêtes intégrée ;
• Prix de licence non prohibitif ;
Inconvénients :
• GC limitée à la gestion de versions ;
• Aucune approche réelle de gestion de
processus ;
• Convivialité limitée de l’interface graphique,
réalisée avec Tcl/Tk ;
• Aucune intégration des IDE connue à ce jour ;
Autres outils commerciaux
Borland StarTeam est un outil possédant les caractéristiques similaires au système ClearCase,
avec une architecture client/serveur et un repository central. StarTeam s’intègre dans les IDE de
Borland, comme JBuilder, et dans Eclipse. Anciennement produit de la société StarBase.
MKS Source Integrity Enterprise est un outil similaire à ChangeMan de Serena (ex-PVCS)
dans les principes du contrôle de versions, avec une orientation gestion de processus et
fonctionnement distribué. Commercialisé par la société américaine MKS.
- 21 -
Outils du domaine public
Devant le nombre important d’outils libres, ne seront présentés ici que les outils les plus répandus
ou complémentaires. Leur étude est en partie basée sur une expérience avec des projets
professionnels et sur les publications des comparaisons et leurs caractéristiques.
CVS
Concurrent Versions System ou CVS est l’outil de gestion de versions sans doute le plus répandu
dans le monde. Outil libre distribué sous la licence GPL (GNU Public License) commune aux
logiciels open-source, il est également l’un des systèmes les plus anciens. En effet CVS est basé
sur le système de contrôle de versions RCS (Revision Control System) datant de 1980, qui à son
tour est basé sur l’outil Unix SCCS.
CVS dispose d’un système de contrôle de versions fiable, bien que limité, et gère les
développements concurrents. Son architecture est de type client/serveur avec un unique
repository et des espaces de travail clients communicant via TCP/IP par protocoles RSH et SSH.
L’utilisation de base se fait via la ligne de commande, bien que de nombreux logiciels libres
additionnels proposent une interface graphique (exemples : TortoiseCVS, WinCVS etc.).
CVS existe sur de nombreuses plates-formes : Unix/Linux/Windows/MacOS pour les clients,
mais Windows n’est pas supporté par le serveur. A noter que de nombreux portails Internet de
développement open-source, tels que sourceforge.net ou tigris.org, utilisent CVS pour tous les
projets partagés.
Avantages :
• Standard libre et largement répandu ;
• Contrôle de versions et des développements
concurrents ;
• Mise en œuvre relativement simple ;
• Clients largement multi plate-forme ;
• Nombreux logiciels additionnels, dont des
interfaces graphiques (TortoiseCVS) ;
• Intégration dans IDE Eclipse ;
• Projet mature ;
Inconvénients :
• Aucune approche de gestion de tâches ;
• Pas d’interface graphique standard ;
• Contrôle de versions limité : mauvaise gestion
des renommages, pas d’atomicité des
changements, utilisation des branches
complexe, algorithme de fusion simpliste ;
• Gestion des fichiers binaires approximative ;
• Aucune évolution prévue ;
• Le serveur ne supporte pas Windows ;
Malgré les points faibles, CVS peut et est utilisé avec succès pour des projets de taille
raisonnable en associant à l’outil une méthode de travail et une rigueur dans l’utilisation.
Cependant, c’est certainement à cause de ces points faibles que de nombreux projets alternatifs
ont fleuris récemment.
Subversion
Subversion se définit comme étant un CVS amélioré. Du fait, leurs architectures sont très
similaires et les commandes sont pratiquement identiques. Les améliorations concernent surtout
les limitations de CVS liés à la gestion de versions. Ainsi Subversion dispose de la gestion des
- 22 -
changements de noms des fichiers et des répertoires, de l’atomicité des changements, d’une
fusion des changements améliorée et d’une gestion de fichiers binaires incrémentale.
Tout comme avec CVS, le serveur de Subversion ne supporte pas la plate-forme Windows, mais
uniquement Linux, Unix et MacOS. En revanche les clients sont totalement multi plate-forme.
Avantages :
• Proche des standards CVS ;
concurrents complet ;
• Différentiation des fichiers binaires ;
• Mise en œuvre relativement simple ;
• Clients largement multi plate-forme ;
• Intégration dans l’explorer de Windows et outil de
fusion avec TortoiseSVN ;
• Intégration dans IDE Eclipse ;
• Projet actif ;
Inconvénients :
• Aucune approche de gestion de processus ;
• Pas d’interface graphique standard ;
• Le serveur ne supporte pas Windows ;
Subversion semble être une alternative prometteuse à CVS et s’inscrit dans son continuation.
Cependant il s’agit d’un projet récent, débuté en 2003, et qui n’a pas encore fait ces preuves. Ce
système est disponible sous licence libre similaire à Apache ou à GPL.
Monotone
Le projet Monotone, débuté en 2003, a une approche similaire à celle de BitKeeper. Cet outil de
gestion de versions privilégie l’intégrité des données et l’environnement distribué. Son
architecture est de type peer-to-peer, avec les repository distribués et une protection des données
accrue grâce à la cryptographie, notamment à SHA1 et à GPG. La communication réseau se fait
via un protocole propre, appelé netsync.
Monotone possède sa propre interface graphique (MonotoneViz) et un algorithme de fusion
amélioré. En revanche ce système n’attribue pas de numéros de versions aux données, mais se
base sur leurs hash code, ce qui est en soi plus sûr, mais confus pour l’utilisateur. Les versions
des fichiers binaires sont différentiés et archivés de manière incrémentale, grâce à la technologie
xdelta (également un projet libre)
Disponible sous licence GPL, Monotone existe en distributions binaires Windows et Linux, ainsi
que sous forme de code source. Comme la plupart des outils alternatifs à CVS, il propose un
mécanisme de migration de projet depuis ce dernier vers Monotone.
Avantages :
• Architecture distribuée P2P ;
• Accent sur la sécurité des données :
cryptographie, réplication ;
• Différentiation des fichiers binaires ;
• Projet actif ;
Inconvénients :
• Pas de distributions binaires UNIX ;
• Protocole réseau propriétaire ;
• Indentification des versions de fichiers basée
sur leurs hash codes et difficilement
interprétable par l’utilisateur ;
• Pas d’intégrations d’IDE à ce jour ;
• Peu répandu, version bêta ;
- 23 -
Le projet Monotone est techniquement ambitieux et novateur, mais se trouve sur un stade de
développement prématuré et ne propose qu’une version bêta du logiciel.
Darcs
Darcs est également un système de gestion de versions distribué, basé sur l’architecture peer-topeer. Réputé simple d’utilisation, il dispose d’un contrôle de versions complet. Darcs est
disponible sous licence GPL sur la plupart des plates-formes Unix/Linux, MacOS et Windows.
Avantages :
• Architecture distribuée P2P ;
• Sécurité des données : cryptographie,
réplication;
• Facilité d’utilisation ;
• Projet actif ;
Inconvénients :
• Manque d’intégrations aux IDE ;
• Pas d’interface graphique ;
• Encore peu répandu et peu mature ;
GNU Make
Les outils libres présentés précédemment sont des gestionnaires de versions et non de
configurations dans le sens propre du terme. Dans ce domaine, un outil tient une place
essentielle : Make. Il s’agit véritablement de l’ancêtre de tous les systèmes de construction de
programmes exécutables.
GNU Make est une implémentation multi plate-forme de l’outil Make fourni dans les
implémentations du système UNIX. Il permet la construction de l’exécutable à partir d’un code
source grâce à un ensemble de règles logiques, similaires au langage Prolog. Ces règles sont
décrits dans les fichiers de configuration d’un projet logiciel, appelés Makefile, et interprétées par
la commande make (ou gmake pour la version GNU) afin de vérifier les dépendances, d’exécuter
le compilateur du langage de programmation et de lancer l’édition des liens avec les
bibliothèques externes et les composants compilés. Toutes ces étapes sont effectués avec des
outils tiers : compilateurs, éditeurs de liens (linkers) etc.
Avantages :
• Standard incontournable ;
• Principe de fonctionnement simple ;
• Multi plate-forme (essentiellement UNIX) ;
• Intégration dans les IDE ;
Inconvénients :
• Outil archaïque ;
• Aucune d’interface graphique ;
• Ecriture des règles laborieuse ;
• Gestion de récursivité manuelle ;
GNU Configure
Les outils configure, autoconf et automake complètent les possibilités de Make. Ils permettent
d’ajouter un niveau d’abstraction dans la description des règles et ainsi permettre une utilisation
plus générique. Cela est rendu possible en associant des prototypes génériques des Makefiles
avec une analyse et un contrôle de l’environnement de la plate-forme de développement – tâche
faite manuellement avec Make.
- 24 -
La mise en œuvre de Configure est complexe et bien plus laborieuse que celle de Make et est
surtout utilisée dans les distributions des sources afin de faciliter leur exploitation par tous les
utilisateurs. Configure génère les Makefiles nécessaires à Make et ne remplace pas ce dernier.
Avantages :
• Facilite l’utilisation de Make ;
Inconvénients :
• Aucune d’interface graphique ;
• Mise en place très laborieuse ;
• UNIX et Linux uniquement ;
Apache Ant
Ant (fourmi en français) est une alternative à Make. Totalement multi plate-forme, car écrit
entièrement en Java, cet outil fonctionne à la manière similaire à Make, avec une différence
notable : les fichiers de règles ne sont pas des Makefiles standards, mais des règles XML
particulières. L’utilisation de Ant est facilitée par son intégration dans les IDE tels que Eclipse.
Avantages :
• Totalement multi plate-forme, car 100% Java ;
• Utilise les standards actuels : XML ;
• Intégration dans l’IDE Eclipse ;
Inconvénients :
• Pas d’interface graphique propre ;
• Ecriture des règles non moins laborieuse ;
Bugzilla
Le logiciel Bugzilla est distribué par l’organisation Mozilla, connue par ces applications Internet
libres. Il s’agit d’un système de gestion des requêtes utilisateur liées aux bugs (d’où l’origine du
nom). Ce système client/serveur dispose d’une base de données contenant des requêtes
d’améliorations et de correction de problèmes d’un produit logiciel. Bugzilla offre les
fonctionnalités du monitoring des taches, de contrôle et de validation de changements. Le serveur
Bugzilla s’intègre avec un serveur HTTP et le client est simplement un navigateur Internet.
Outre Mozilla, Bugzilla est utilisé dans de nombreux projets et en particulier il peut être interfacé
avec le logiciel Perforce. Il s’agit d’un outil complémentaire sérieux pour les outils vus
précédemment.
Avantages :
• Utilisation via navigateur Internet ;
• Système de contrôle, de validation et de
monitoring des taches assez complet ;
• Multi plate-forme et multi langue ;
• Mozilla est un éditeur de logiciels libres connu et
réputé ;
• Intégration avec certains outils de GCL tiers ;
Inconvénients :
• Nécessite un serveur HTTP ;
Autres outils libres
L’annexe II propose une liste exhaustive des projets de logiciels libres et commerciaux dédiés à
la GCL.
- 25 -
Synthèse comparative
Le tableau ci-dessous présente une comparaison très succincte des caractéristiques majeures des
outils cités précédemment. L’annexe I propose une comparaison plus détaillée de leurs
fonctionnalités.
Contrôle de
versions
Contrôle de
configurations
Traçabilité
des requêtes
Gestion de
processus
Interface
graphique
Particularités
diverses
ClearCase
OUI
OUI
OUI
OUI (option)
OUI
Gamme de
produits
ChangeMan
OUI
OUI
OUI
OUI (option)
OUI
Gamme de
produits
Synergy
OUI
OUI
OUI
OUI
OUI
Gamme de
produits
VSS
OUI (limité)
NON
NON
NON
OUI
MS Windows
uniquement
Perforce
OUI
NON
OUI
NON
OUI
Performances
BitKeeper
OUI
NON
OUI
NON
OUI
P2P, Aucune
intégration IDE
CVS
OUI (limité)
NON
NON
NON
NON *
Intégré avec
IDE Eclipse
Subversion
OUI
NON
NON
NON
NON *
CVS amélioré
Monotone
OUI
NON
NON
NON
OUI
P2P, Version
bêta
Darcs
OUI
NON
NON
NON
NON
P2P
Make
NON
OUI (limité)
NON
NON
NON
Standard
Ant
NON
OUI (limité)
NON
NON
NON
Java, intégré
avec Eclipse
Bugzilla
NON
NON
OUI
OUI (limité)
OUI
Application web
* existe via outils complémentaires ou IDE.
- 26 -
Partie IV - Mise en œuvre
Standards et recommandations
La démarche de la qualité est au cœur de tous les projets industriels et se conforme aux
recommandations des standards tels que ISO 9001 : 2000. Ce standard concerne tous les
domaines et définit un plan de gestion de la qualité au sein d’une entreprise. Un plan de qualité
d’un projet logiciel, conforme à ce standard, définit les procédures de gestion parmi lesquelles en
règle générale se trouve la gestion de configuration.
Plan de gestion de configuration
Le plan de gestion de configuration décrit la mise en place de cette gestion au sein d’un projet. Il
existe des recommandations telles que le standard de l’organisme international IEEE : IEEE 8281998. Ce standard définit un plan minimal de GCL comprenant les parties suivantes :
• Introduction : présentation succincte du plan ;
• Organisation : identification des autorités responsables de GCL ;
• Activités : activités de GCL appliquées au projet ;
• Agenda : planification des activités de GCL et coordination avec les autres activité du
projet ;
• Ressources : identification des ressources humaines, matérielles et logicielles nécessaire à
l’exécution du plan ;
• Maintenance du plan : identifie la procédure du maintien du plan durant tout le cycle de
vie du projet ;
Comme tous les standards ouverts, IEEE 828 laisse libre choix des méthodes de gestion et
indique seulement les points qui doivent être pris en compte. Le plan décrit comment, quand et
par qui ces points seront gérés.
Il existe également des guides de référence de GCL, dont IEEE/EIA 12207 qui est une
implémentation industrielle des standards IEEE en matière de gestion du développement logiciel.
Bonnes pratiques
Bien qu’il existe aujourd’hui des outils intégrés permettant une mise en place de la GCL, leurs
utilisation par les acteurs des projets n’en est pas moins importante au succès et à l’efficacité de
ces outils. Ci-après quelques règles et « bonnes pratiques1 » de la gestion de configuration, qui
sont particulièrement importantes avec les outils ouverts tels que CVS.
Espace de travail
•
•
•
•
Ne pas partager les espaces de travail ;
Ne pas travailler en dehors des espaces de travail gérés ;
Mettre à jour régulièrement l’espace de travail ;
Archiver régulièrement son travail dans le repository ;
1
Une partie de ces recommandations est issue de l’article « High-level Best Practices in SCM » publié par Laura Wingerd et
Christopher Seiwald de Perforce Software.
- 27 -
Ligne de
développement et
branches
•
•
•
•
Avoir une ligne de développement principale ;
Ne pas créer de branches qu’en cas de besoin précis ;
Ramifier plutôt que de figer les versions ;
Propager et fusionner les modifications entre branches ;
Construction de
programme
exécutable
•
•
•
Archiver les éléments d’origine ;
Construire régulièrement ;
Séparer les objets construits des sources d’origine ;
Gestion de processus
•
•
•
•
•
Planifier les modifications et les associer à des taches ;
Assigner les taches aux développeurs ;
Organiser le suivi des modifications ;
Organiser le suivi des demandes de modifications ;
La documentation doit être maintenue à jour et archivée au
même titre que le code source ;
CVS, Subversion,
VSS et simili.
•
Toujours mettre à jour l’espace de travail avant de importer ces
changements dans le repository ;
Résoudre les conflits éventuels et tester avant d’importer les
changements ;
Ne pas importer de changements incomplets ;
Ne pas importer de changements qui constituent plusieurs
taches à la fois ;
Toujours écrire un commentaire associé à la tache importée ;
Définir une convention de noms des versions et des branches ;
•
•
•
•
•
Exemple de mise en œuvre
Afin d’assimiler les concepts présentés dans ce document, prenons un exemple concret de projet
imaginaire. La description de la mise en place de GCL pour ce projet dans les paragraphes
suivants se conformera au plan exposé plus haut. Bien entendu il sera extrêmement synthétique
car il ne s’agit ici que d’un exemple :
Introduction
Le projet P, qui commencera en juin 2005, consiste à réaliser un logiciel pour plates-formes Windows et
Linux. Son équipe se compose de 10 personnes, dont A – le responsable du projet. Le logiciel sera écrit en
langage Java avec des extensions natives C++. La première livraison commerciale est prévue en juin 2006.
Organisation du projet
En tant que chef de projet, A sera le responsable de l’application des méthodes de gestion de configuration.
Il sera chargé de valider tous les changements apportés dans le projet.
Activités
Les activités de la GCL du projet P sont :
1. Gestion de développements parallèles (détail) ;
2. Gestion des versions intermédiaires (détail) ;
3. Gestion des configurations matérielles : Linux et Win32 (détail) ;
- 28 -
4.
5.
6.
Mise en places des tests des versions de livraison et gestion des requêtes de corrections (détail) ;
Gestion des releases ;
Gestion des requêtes des clients et de la maintenance des releases ;
Agenda
Mai 2005 : démarrage des activités 1, 2, 3 ;
Novembre 2005 : tests de la version alpha, mise en place de l’activité 4 ;
Avril 2006 : tests de la version bêta, activité 4 ;
Juin 2006 : livraison de la version 1.0, activité 5 et 6 ;
Ressources
Humaines : 9 développeurs sur deux sites différents et 1 chef de projet.
Logicielles :
• Utilisation de Subversion intégré avec Eclipse pour les activités 1, 2 et 5 ;
• Règles d’utilisation du gestionnaire de version avec les conventions de noms ;
• Utilisation de Ant intégré avec Eclipse et de Microsoft Visual C++ pour l’activité 3 ;
• Utilisation de Bugzilla pour les activités 4 et 6 ;
Maintenance du plan
B, le responsable qualité extérieur au projet, sera chargé conjointement avec A de réviser le plan de GCL
selon les besoins, pendant le déroulement du projet.
- 29 -
Conclusion
A fil des pages de ce document, la gestion de configuration logicielle se révèle d’être partie
intégrante de la gestion du cycle de vie d’un projet. Tous les projets, qu’ils soient de
développement logiciel, de gestion de documentation ou de publication électronique sont amenés
à rechercher des solutions de gestion de configuration.
Les principes de gestion des versions et des changements sont connus depuis des dizaines
d’années et aujourd’hui les systèmes logiciels les implémentent de manière optimale. La
nouveauté est la généralisation de l’approche de gestion de processus, qui tend à réunir la gestion
traditionnelle et ces aspects techniques et ainsi améliore les méthodes et la qualité des projets.
Le choix des solutions logicielles spécialisées dans le domaine est très large. Les produits
commerciaux sont bien établis sur le marché, mais le nombre croissant des projets de logiciels
libres qui y sont présents témoigne de l’intérêt des développeurs pour la gestion de configuration
et rend les outils les plus modernes accessibles à tous. Ainsi, bien que ce domaine ne soit pas
nouveau, les outils actuels, en particulier CVS, et les outils les plus récents contribuent faire de la
gestion de configuration une pratique courante et incontournable. Aussi, afin qu’elle soit efficace,
les acteurs et les responsables des projets doivent la planifier et choisir les méthodes et les outils
les mieux adaptés à leurs besoins. Les recommandations et les standards industriels existent pour
les aider dans cette tache.
- 30 -
Bibliographie
Publications
•
Steve Berczuk, Brad Appleton : « Software Configuration Management Patterns »,
Addison-Wesley, Boston, MA, 2002
•
« IEEE Standard for Software Configuration Management Plan : IEEE 828-1990 »,
IEEE, New York, NY, 1990
•
Ueli Wahli, Jennie Brown, Matti Teinonen, Leif Trulsson : « ClearCase Redbook : A
Clear Case for IBM Rational ClearCase », IBM Corp. 2004. http://ibm.com/redbooks
•
Laura Wingerd, Christopher Seiwald : « High-level Best Practices in Software
Configuration Management », article, Perforce Software :
http://www.perforce.com/perforce/bestpractices.html
•
Per Cedeqvist : « Version Management with CVS », Free Software Foundation, 19932005 : https://www.cvshome.org/docs/manual
Internet
•
Ressource dédiée à la gestion de configuration : http://www.cmcrossroads.com/
•
Site de l’éditeur du logiciel BitKeeper : http://www.bitkeeper.com/
•
Site du logiciel Subversion : http://subversion.tigris.org/
•
Site de la compagnie Perforce, éditeur du logiciel du même nom :
http://www.perforce.com
•
Site de la compagnie Serena, éditeur de ChangeMan : http://www.serena.com/
•
Site du logiciel Monotone : http://www.venge.net/monotone/
•
Site du logiciel Aegis : http://aegis.sourceforge.net/index.html
•
Site du produit Synergy : http://www.telelogic.com/products/synergy/
•
Site du logiciel Bugzilla : http://www.bugzilla.org/
•
Site de l’outil GNU Make : http://www.gnu.org/software/make/
- 31 -
Glossaire
.NET
Microsoft Visual .NET : environnement de développement de Microsoft pour la
plate-forme Windows ;
Client/Serveur
Architecture d’application avec en général un programme serveur central et
plusieurs programmes clients communicant avec lui ;
CVS
Concurrent Versions System : logiciel libre de gestion de versions (voir paragraphe
consacré : CVS) ;
Eclipse
Logiciel libre suite à une initiative d’IBM, propose un IDE multi plate-forme pour
les développements Java essentiellement ;
GCL (SCM)
Gestion de Configuration Logiciel (Software Configuration Management) ;
GNU
GNU = GNU is Not Unix : définition récursive. A l’origine GNU est une
organisation proposant des implémentations des outils Unix open-source,
indépendants de implémentations Unix propriétaires ;
GPG
GNU Privacy Guard : Technique de cryptographie similaire au PGP
GPL
GNU Public License : licence assurant une libre distribution de logiciels opensource ;
IDE
Integrated Development Environment (Environnement de développement intégré) :
application qui intègre tous les outils nécessaires au développement logiciel ;
IEEE
Institute of Electrical and Electronics Engineers : organisation internationale
d’origine américaine qui, entre autres, publie des standards et des recommandations
aux industriels du domaine électronique et informatique ;
Java
Langage de programmation indépendant de plate-forme matérielle, technologie
initiée par Sun Microsystems ;
Open-source
Logiciels libres avec le code source disponible gratuitement, souvent distribués
avec une licence GPL ;
Peer-to-peer
(P2P)
De l’anglais : poste à poste : architecture d’application distribuée où chaque
programme client est lui-même un serveur (voir client/serveur) ;
Release
Version d’un logiciel livrée à l’extérieur ;
SHA1
Algorithme de calcul de hashcode sécurisé ;
SunOS, Solaris
Système d’exploitation UNIX de Sun Microsystems ;
TCP/IP
Protocole de transmission de données Internet : Transmission Control Protocol /
Internet Protocol ;
Version bêta
Version d’un logiciel en phase de test avant sa livraison ;
XML
eXtended Markup Language : langage de balises descriptif (extension de SGML et
du très connu HTML) ;
- 32 -
Annexe I – Comparatif des logiciels dédiés à la GCL
Caractéristiques générales
IBM ClearCase
Serena ChangeMan
Perforce
BitKeeper
Telelogic Synergy
Microsoft VSS
CVS
Subversion
Monotone
AEGIS
Darcs
ArX
ANT
GNU Make
Bugzilla
Type d'application
solution intégrée
solution intégrée
gestion de versions
gestion de versions
solution intégrée
gestion de versions
gestion de versions
gestion de versions
gestion de versions
gestion de versions
gestion de versions
gestion de versions
configurations
configurations
gestion de requêtes
Gestion de
processus
ClearQuest
Dimensions
NON
NON
OUI
NON
NON
NON
NON
NON
NON
NON
N/A
N/A
OUI
GUI
OUI
OUI
OUI
OUI
OUI
OUI
NON*
NON*
OUI
NON
NON
NON
NON
NON
HTML
Plate-forme
MULTI
MULTI
MULTI
MULTI
MULTI
Windows
MULTI**
MULTI**
MULTI
UNIX/Linux
MULTI
MULTI
JavaVM
MULTI
MULTI
Licence
commerciale
commerciale
commerciale
commerciale
commerciale
commerciale
GPL
GPL
GPL
GPL
GPL
autre
GPL
GPL
MozillaPL
* Disponibles sur certaines plates-formes via produits tiers
** Serveur non disponible pour Win32
Caractéristiques techniques
IBM ClearCase
Serena ChangeMan
Perforce
BitKeeper
Telelogic Synergy
Microsoft VSS
CVS
Subversion
Monotone
AEGIS
Darcs
ArX
ANT
GNU Make
Bugzilla
Atomicité
des commit
OUI
OUI
NON
OUI
OUI
NON
NON
OUI
OUI
OUI
OUI
OUI
N/A
N/A
N/A
Fichiers
binaires
OUI
OUI
OUI
OUI, deltas
OUI
OUI
OUI, deltas
OUI, deltas
OUI
OUI
OUI
N/A
N/A
N/A
Builds
OUI
OUI
NON
NON
OUI
NON
NON
NON
NON
NON
NON
NON
OUI
OUI
NON
Fusion
automatique
OUI
OUI
OUI
3WAY
OUI
SIMPLE
SIMPLE
DIFF3
3WAY
3WAY
3WAY
3WAY
N/A
N/A
N/A
Branches
OUI
OUI
OUI
OUI
OUI
Limité
OUI
OUI
OUI
OUI
OUI
OUI
N/A
N/A
N/A
Renom
mage
OUI
OUI
OUI
OUI
OUI
NON
NON
OUI
OUI
OUI
OUI
OUI
N/A
NON
N/A
Architecture /
réseau
Client/Serveur
Client/Serveur
Client/Serveur
P2P
Client/Serveur
Client/Serveur
Client/Serveur
P2P
P2P
P2P
P2P
Local
Local
Client/Serveur
Plate-forme
MULTI
MULTI
MULTI
MULTI
MULTI
Windows
MULTI**
MULTI**
MULTI
UNIX/Linux
MULTI
MULTI
JavaVM
MULTI
MULTI**
- 33 -
Annexe II – Liste de logiciels dédiés à la GCL
Aegis
http://aegis.sourceforge.net/
Apache Ant
http://ant.apache.org/
ArX
http://www.nongnu.org/arx/
BitKeeper (commercial)
http://www.bitkeeper.com/
Bugzilla
http://www.bugzilla.org/
ChangeMan (PVCS)
(commercial)
http://www.serena.com/
ClearCase (commercial)
http://www.ibm.com/software/awdtools/clearcase/index.html
Code Co-op (commercial)
http://www.relisoft.com/co_op/
Codeville
http://codeville.org/
CVS
https://www.cvshome.org/
Darcs
http://abridgegame.org/darcs/
DCVS
http://www.elegosoft.com/index_dcvs.html
GNU Arch
http://www.gnuarch.org/
GNU Make
http://www.gnu.org/software/make/
Jedi VCS
http://jedivcs.sourceforge.net/
META-CVS
http://users.footprints.net/~kaz/mcvs.html
MKS (commercial)
http://www.mks.com/products/sie
Monotone
http://www.venge.net/monotone/
OpenCM
http://www.opencm.org/
Perforce (commercial)
http://www.perforce.com/
PRCS
http://prcs.sourceforge.net/
StarTeam (commercial)
http://www.borland.com/starteam/
Stellation
http://www.eclipse.org/stellation/
Subversion
http://subversion.tigris.org/
Superversion
http://www.superversion.org/
SVK
http://svk.elixus.org/
Synergy (commercial)
http://www.telelogic.com/products/synergy/index.cfm
TortoiseCVS
http://www.tortoisecvs.org/
TortoiseSVN
http://tortoisesvn.tigris.org/
Vesta
http://www.vestasys.org/
- 34 -

Le point sur la gestion de configuration - miniwebpage T. Jgenti

Transcription

Documents pareils

Forum: Généralités

activation windows xp oem - MetaGames-EU

maquette page par page

construction vente location

Téléchargement de Sauvegarde Guppy

ACROSS THE UNIVERSE (Collector Limité)

Information de Service

pack wc prima d`angle multi

Eclipse pour les null

ZION CUP 2010