À la recherche de la qualité Motivations (one2one) Développer : 1 utilisateur 1 fichier/classe/package Cycle prog: 1ère version tests correction bugs version corrigée tests difficiles/fonctionnels version OK (réécriture). MAIS Lors de la correction de bugs, on peut avoir envie de revenir en arrière si on se lance dans de trop grosses modifications, Souvent on se perd dans nos propres corrections, La correction d un problème provoque 3 nouveaux problèmes ou fait réapparaitre un bug déjà corrigé. La correction incrémentale doit être ordonnée La solution : gestion d un historique du fichier. Motivations (one2many) Développer un projet : 1 utilisateur 1 projet (n modules/packages) Cycle prog : développement par bouts tests unitaires (avec bouchons?) assemblage tests ajustements validation OK (réorganisation /optimisation / simplification) MAIS Déplacement de bout de codes d un endroit à l autre, Version incrémentale des différents blocs à synchroniser Tests spécifiques validés, impactés par des modifications/correction, à réajuster pour être revalider. Savoir s arrêter La solution : gestion du projet (Roadmap, schéma, cas d utilisation). 1
Motivations (many2many) Développer en équipe n utilisateurs 1 projet (décomposé en modules) Cycle en V : spéc / découpage / répartition / dev / tests U / assemblage / coordination / correction / réorganisation / intégration / recette MAIS Diversité de styles, de rythmes de développement, de compréhensions, d implications Coordination (comité de développement, affectation des bugs, unions des forces) Savoir arrêter une version stable obtenir une version stable La solution : gestion de projet et d équipe et de version Motivations (many2one) Développer en parallèle n utilisateurs 1 projet (module commun) Cycle prog : accès concurrent synchrone/asynchrone - fork/branchements tests bugs compréhension bug affectation corrections - tests module validation (homogénéisation) - intégration - recette MAIS Développement cyclique Problème lors des fusions Style de développements différents Modifications sur différentes versions historiques Retour en arrière et réincorporation d un bout de dev La solution : gestion de configuration Sur le thème de la Version La gestion de version CVS SourceSafe, la solution M$ La gestion de configuration ClearCase (et ClearQuest) SubVersion Conclusion 2
La gestion de versions Travaux préliminaires SCCS [Bell Labs 72] (source code control system) Get / Edit / Put Successeur RCS [80] (Revision Code System) Utilise le Diff et stocke le résultat Fichier décrit de manière incrémentale one2one Le plus répandu CVS [84] (Concurrent Version System) Many2many Les commandes add /delete Ajoute ou supprime un fichier dans le repository Ckeck out (out of CVS) Check in (ou commit) Vision client serveur Importe ou exporte une révision d un fichier Numérotation automatique Update mise à jour locale de la version CVS si OK commit si KO, résolution humaine des conflits puis commit L environnement de dev Ligne de commande (pour les véritables) GUI sur la plupart des plateformes En fait CVS n est qu une gestion de fichiers intelligente PlugIn nombreux Eclipse, JavaIDE, NetBeans, Client / Serveur un peu d administration possible 3
Quelques définitions Repository The repository is where the current and historical file data is stored, often on a server. Sometimes also called a depot. Working copy The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. Conceptually, it is a sandbox. Check-out A check-out (or checkout or co) creates a local working copy from the repository. Either a specific revision is specified, or the latest is obtained. Commit A commit (check-in, ci or, more rarely, install or submit) occurs when a copy of the changes made to the working copy is written or merged into the repository. Quelques définitions 2 Change A change (or diff, or delta) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems. Change list On many version control systems with atomic multi-change commits, a changelist (or change set) identifies the set of changes made in a single commit. This can also represent a sequential view of the source code, allowing source to be examined as of any particular changelist ID. Resolve The act of user intervention to address a conflict between different changes to the same document. Baseline An approved revision of a document or source file from which subsequent changes can be made. Quelques définitions 3 Update An update (or sync) merges changes that have been made in the repository (e.g. by other people) into the local working copy. Branch A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may be developed at different speeds or in different ways independently of the other. Merge A merge or integration brings together two sets of changes to a file or set of files into a unified revision of that file or files. This may happen when one user, working on those files, updates their working copy with changes made, and checked into the repository, by other users. Conversely, this same process may happen in the repository when a user tries to check-in their changes. It may happen after a set of files has been branched, then a problem that existed before the branching is fixed in one branch and this fix needs merging into the other. It may happen after files have been branched, developed independently for a while and then are required to be merged back into a single unified trunk. 4
Quelques définitions 4 Tag A tag or release refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number. Import An import is the action of copying a local directory tree (that is not currently a working copy) into the repository for the first time. Export An export is similar to a check-out except that it creates a clean directory tree without the version control metadata used in a working copy. Often used prior to publishing the contents. Conflict A conflict occurs when two changes are made by different parties to the same document or place within a document. When the software is not intelligent enough to decide which change is 'correct', a user is required to resolve such a conflict. La résolution des conflits 2 way merging Diff(A,B) et choix du meilleur remplacement A mis à jour par B ou B mis à jour par A 3 way merging A, B, Parent commun diff(parent,a), diff(parent, B) Incorporation simultanée parent : Parent mis à jour par A et B Cela n évite pas tous les conflits new merging algorithm (Codeville) La solution Microsoft : Visual Source Safe Outil intégré à Visual Studio Compatible Microsoft suite Peut être transparent en.net Reconnu OK pour petits et moyens projets Peut être couplé à SourceAnyWhere en mode distant 5
SourceAnyWhere La gestion de la configuration Motivations : gestion technique qu est ce qui a changé? Relier les changements entre eux? Manipuler différentes versions de différents produits assemblés fixer les releases, vérifier la cohérence + Build management Environnement management La gestion de la configuration Motivations Organisationnelles Contrôle les modifications imposées Audit sur les modifications : Qui a fait quoi? Qu a fait qui? Assistance au travail en équipe Etude d impact en cas de découverte de bug Permettre de coordonner le processus de développement du logiciel 6
Intérêts Génie Logiciel Contrôle Méthode de suivi et d évolution de version Gestion Identification et guidage durant le cycle de vie du logiciel Economie Détection des bugs en amont, étude d impact simplifié, orientation des corrections. Qualité «La vérification automatique au fil de l eau d un processus humain conduit à une meilleure productivité» Les actions à effectuer 1/ Politique de gestion du configurateur de version 2/ Identification des Produits/Modules/SP à suivre 3/ Gestion des versions effective 4/ Validation des mises à jour 5/ Décision Release Intérêts supplémentaires Processus prévisible Plus grande flexibilité Communication entre développeurs Communication (exportation) vis-à-vis de l extérieur 7
Rational Clear Case Outil de CM d IBM Intégré à Rational + Rational Clear Quest Suivi de modif Suivi de bug Flux de soumission, de correction, de notification Versionning New Generation SubVersion (SVN) [2004] est le prolongement et l extension de CVS Réimplémentation du module de gestion Correction de lacunes de CVS (versionning de projets, renommage, commits non atomiques, liens symboliques ) Simplification d utilisation Meilleurs algorithmes de fusion Scripts aisés Nouveautés fonctionnelles Versionning des répertoires Versionning des meta-données (propriétés, droits) Branche, Label (tag), Répertoire sont identiquement gérés copy (complexité linéaire pour les opérations de gestion en taille de modifs non en taille de fichiers!) Fichier binaire (algorithme diff spécifique) Client WEB cvs2svn! 8