Contrôle de Version sur Mac OS X, Part 3
Introduction
Bienvenue, à nouveau.
Dans le premier article de cette série, vous avez découvert la gestion de code source et quelques uns des ces concepts.
Le second article vous a donné une chance d’appliquer cette nouvelle connaissance en utilisant CVS depuis la ligne de commande, ainsi qu’au travers de Project Builder, sur un simple programme Cocoa — MyPing.
Dans cet article, le dernier, de cette série, nous allons voir comment créer des versions de logiciels en utilisant les commandes tag et branch, ainsi qu’avec des programmes Mac OS X pour interagir avec CVS.
Ajouter de Nouvelles Fonctionnalités à MyPing
La première version de MyPing contenait un minimum de fonctionnalités.
L’application permettait de pinger un serveur, vérifier le nombre de pings, l’intervalle entre chaque pings, et afficher le résultat du ping.
Ajoutons deux nouvelles fonctionnalités qui permettront de logger le résultat du ping dans un fichier et effacer le contenu de la fenêtre texte entre deux pings.
J’ai ajouté ces fonctionnalités à MyPing, qui peut être téléchargé et intégré à votre dernière version.
Les ajouts sont notifiés dans le code par des commentaires.
Vous aurez également besoin de mettre à jour le fichier Nib pour prendre en compte les modifications de l’interface.
Une fois intégré, assurez-vous d’effectuer un commit pour que CVS soit mis à jour.
L’essentiel Concernant les Livraisons (release)
Avant d’utiliser les commandes CVS pour des livraisons de code, voyons rapidement l’essentiel de la gestion de livraison de code.
Avec cette connaissance, vous comprendrez mieux le processus de la livraison de code et comment cela fonctionne.
Si vous le savez déjà, vous pouvez passer cette section.
Comme vous l’avez vu dans le premier article, le contrôle de version est un processus, effectué à l’aide d’un logiciel, qui vous aide gérer les étapes du processus de développement logiciel.
Ceci comprend la sauvegarde des modifications des fichiers source de votre projet, contrôler l’accès aux fichiers partagés et gérer les livraisons de code.
Bien que la livraison de code varie de projet en projet et de secteur d’activité en secteur d’activité, nous pouvons observer quelques propriétés générales qui nous permettent de mieux comprendre ce processus.
Il y a typiquement trois acteurs dans le processus de livraison : les développeurs, les chargés de maintenance et les responsables de livraisons (il peut y en avoir plus comme par exemple des testeurs).
Un développeur est chargé d’écrire le code, corriger les erreurs et ajouter les fonctionnalités aux composants du logiciel.
Les chargés de maintenance sont responsables d’une partie spécifique (ou plusieurs) du logiciel.
Ils prennent en compte les ajouts des développeurs, les vérifient et les intègrent au code.
Ils peuvent également développer du code pour un module.
Le responsable de livraison effectue les étapes nécessaires pour assembler le tout et livrer le logiciel.
Ceci implique de tester, communiquer avec les chargés de maintenance, forcer un gel du code, effectuer des revues de code/fonctionnalités, etc…
Le responsable de livraison peut être une personne ou un groupe.
Un gel du développement est une décision, généralement prise par le responsable des livraisons, qui bloque une partie, ou tout, type de développement sur le logiciel.
Un gel peut se situer au niveau des fonctionnalités, dans ce cas, aucune nouvelle fonctionnalité ne peut être ajoutée (mais de petites modifications comme des corrections peuvent être appliquées) ou à tout niveau, dans ce cas, aucune modification ne peut être apportée.
Dans de nombreux projets, la gestion des livraisons fonctionne comme ceci.
Les développeurs envoient leur code (corrections, patch, fonctionnalité, etc…) au responsable de la maintenance du module.
Celui-ci accepte ou rejette les modifications et intègre le code dans la version en cours du module.
Une fois que le responsable du projet décide d’effectuer une livraison d’une nouvelle version (la règle varie d’un projet à un autre), le responsable de livraison décide d’un gel du développement, récupère les mises à jour des différents modules, accepte ou rejette les modifications, effectue et coordonne les tests, effectue des revues de code et s’assure de la stabilité de la nouvelle version.
Une fois que la version est prête à être livrée, le responsable de livraison fait une annonce de la nouvelle version et la rend disponible au public.
Rappelez-vous que ceci est un cas général ; chaque projet peut, et aura souvent, un modèle de livraison différent (par exemple, le noyau Linux ou le serveur Apache).
Pour le projet MyPing, il n’existe qu’un seul développeur, pour les différents rôle : vous.
Néanmoins, il est utile de comprendre le modèle de base, pour pouvoir voir les différents rôles du cycle de livraison, même si vous effectuez toutes les tâches.
Créer une Version de MyPing
CVS possède deux commandes pour la création de version de code : tag et branch.
Un tag est un label que vous donnez à un ensemble de mises à jour, ou fichiers du projet.
Si vous modifiez des fichiers taggés, et les sauvegardez sur CVS, le tag pointe toujours sur la version du fichiers avant modification.
A tout moment, vous pouvez revenir à cette version en effectuant un check out des fichiers par tag name.
Nous utiliserons la commande tag pour créer une version de MyPing.
La commande branch vous aide à créer et gérer différentes versions du projet — telles que versions de livraison, deboggage et optimization — sans perturber le tronc principal.
Le tronc correspond à l’état courant du développement ; une branche est une version spécialisée, ou une diversion.
Chaque branche a une racine (le point de départ de la branche) et un tip (l’état courant de la branche).
Si vous créez une branche, modifiez des fichiers, et les mettez à jour dans CVS, la racine et le tip contiendront des versions différentes de vos fichiers.
De plus, toutes les mises à jour d’une branche n’affectent pas le tronc, seulement la branche.
Nous utiliserons la commande branch pour créer une version spécialisée, dans notre cas, une correction de bug de MyPing.
Le diagramme suivant montre un example de trois branches issues du tronc, de même que des branches issues de ces branches.
Créer une Version avec Tag
Les étapes suivantes expliquent comment créer une nouvelle version de MyPing.
Etapes 1 : Instituer un Gel du Développement
Instituer un gel du développement du projet MyPing. Plus aucune modification ne doit être apportée.
A ce point, CVS doit être mis à jour (commit).
Etape 2 : Tester la Version
Une fois le gel du développement en place, vous pouvez créer une nouvelle version.
Premièrement assurez-vous que tout fonctionne correctement en effectuant votre batterie de tests.
Pour tous les projets, cela veut dire exécuter un script qui effectuera un test de régression pour vérifier que la version est stable.
Si une modification est apportée, assurez-vous de mettre CVS à jour.
Note : La version de MyPing contient un bug intentionnel.
J’ai fait cela pour montrer comment utiliser la commande branch de CVS pour effectuer des corrections de bug dans des versions antérieures.
Je parle de cette technique dans la section “Mettre à Jour une Version Livrée avec la commande Branch de CVS”.
Etape 3 : Tagger la Version
L’étape suivante consiste à enregistrer la nouvelle version.
Pour cela, vous utiliser la commande tag de CVS pour associer un label avec les fichiers qui font partie de cette version.
% cd MyPing
% cvs tag release_1_0-public-release
Puisque la commande tag ne permet pas l’ajout de commentaires (comme import et commit), c’est une bonne idée que d’ajouter autant d’informations que possible dans le libellé du tag.
Etape 4 : Annoncer la Version
Enfin, informez les utilisateurs que la nouvelle version est prête et indiquez leur où le logiciel peut être téléchargé.
Mise à Jour d’une Version avec branch de CVS
Une tâche de maintenance habituelle consiste à corriger des bugs dans une version.
Si le bug existe dans une version déjà livrée, vous avez un problème.
Comment corrigez-vous le code alors que du nouveau code à été ajouté au tronc ?
Une solution est récupérer la version taggée et corriger le bug, mais maintenant comment faire pour mettre CVS à jour ?
Une autre option est de corriger le bug dans la version courante du code, mais vous risquez de livrer une version instable.
Pour résoudre ce genre de problème, utiliser la commande branch de CVS.
Comme vous l’avez vu auparavant, la commande branch de CVS vous permet de créer et gérer plusieurs versions de votre projet.
En gros, une branche est une version spécialisée de votre programme, prenant racine au niveau du tronc, ou encore d’une autre branche.
Les étapes suivantes vous montrent comment corriger le bug dans la version déjà livrée de MyPing et mettre à jour les modifications dans CVS, en utilisant la comande branch de CVS.
Etape 1 : Récupérer la Version à Mettre à Jour
La première étapes consiste à récupérer la version que vous voulez corriger.
Dans ce cas, la version que nous avons taggée release_1_0-public-release.
% cvs co -d MyPing_release_1_0-public-release -r release_1_0-public-
release MyPing
Etape 2 : Créer une Branche
Pour créer une branche, suivez les étapes suivantes :
- Créer une branche. De façon conceptuelle vous pouvez vous représenter une branche comme prenant racine sur le tronc, démarrant avec un tag.
% cvs tag -b [name-of-branch-tag]}Pour notre projet, faites ce qui suit :
% cd MyPing_release_1_0-public-release % cvs tag -b release_1_0-public-release-branch-bug-fixes - Effectuez un check out de la version nouvellement taggée.
C’est la version que vous souhaitez mettre à jour, qui forme la base de la future nouvelle version.Note : il y existe différentes façon de faire cela, mais ceci est la plus simple et la plus sûre.
% cvs co -d [dir-to-place-version] -r [release-tag] [location-of-dir-in-cvs] % cvs co -d release_1_0-public-release-bug-fixes -r release_1_0-public-release-branch-bug-fixes MyPing - Modifification du code de la branche.
Effectuez les modifications au niveau du code et effectuez un commit au niveau de CVS.
Il est important de vous rappeler que les modifications seront alors apportées au niveau de la branche, pas du tronc.Le bug de MyPing se situe dans la méthode appendOutput dans PingController.m
// ---------------- Begin New Code for Article 3 ------------------ // Log to the file, only if the file point is valid. if (fp != NULL) { fprintf(fp, "%s", [outStr cString]); [AppSupport setStatusMsg:output theMsg:outStr]; [self performSelector:@selector(scrollToVisible:) withObject:nil afterDelay:0.0]; } // ---------------- End New Code for Article 3 ------------------Comme vous pouvez le voir, le bug provient du fait que l’instruction fprintf est localisée entre les accolades.
Pour corriger le problème, supprimez simplement les accolades.// ---------------- Begin New Code for Article 3 ------------------ // Log to the file, only if the file point is valid. if (fp != NULL) fprintf(fp, "%s", [outStr cString]); [AppSupport setStatusMsg:output theMsg:outStr]; [self performSelector:@selector(scrollToVisible:) withObject:nil afterDelay:0.0]; // ---------------- End New Code for Article 3 ------------------Assurez-vous d’effectuer votre batterie de tests et que la version est stable avant de continuer.
- Tagger la branche.
Une fois que les modifications sont complètes, tagger la branche, en incrémentant de 1 après chaque correction.% cvs tag [tag-name] % cvs tag release_1_0-public-release-bug-fixes-fix-number-1
Voici la raison pour laquelle nous re-taggons la branche : il est possible que les modifications apportées à la version dans cette branche doivent être intégrées au tronc.
Par exemple, imaginer la correction d’un bug dans la branche d’une librairie essentielle.
Comme le code de la branche est indépendant du tronc, cela ne corrige pas le bug du tronc, juste celui de la branche.
Etant donné que le bug existe toujours dans le tronc, vous devez corriger ceci en mettant à jour le code du tronc à l’aide de la version corrigée.
Vous re-taggez la branche pour résoudre ce problème.
Imaginez que, après quelques semaines, vous devez corriger un bug sur la branche.
Si la branche n’est pas taggée, la branche contient (à sa racine) la version initiale avant toute modification, la première version livrée.
Si vous appliquez vos modifications au niveau du tronc, il y aura des conflits.
Ceci parce que la commande merge apporte toutes les modifications depuis la racine de la branche jusqu’à sa pointe, qui contient les corrections.
Ces conflits apparaissent, parce que vous avez déjà apporté d’autres modifications après cette première version.
Pour résoudre ce problème, ajoutez un tag sur la branche après sa mise à jour.
Ceci vous permet d’indiquer à CVS de ne prendre en compte que les nouveaux changements au niveau du tronc.
Vous pouvez accomplir cela sans ajouter de nouveau tag en vous appuyant sur les dates, mais cela est souce d’erreur.
En plus, vous avez peut-être remarqué que nous avons ajouté la chaine de caractères -fix-number-k (où k est incrémenté après chaque modification) au nom du tag.
Ceci explique clairement le but de la branche.
Etape 4 : Annoncer la Version
Indiquez aux utilisateurs que la nouvelle version est prête.
Et voilà.
Ces étapes de scénarios de création de versions ne sont qu’un guide et ne présentent pas tout ce qui se passe au niveau de la gestion de versions.
Néanmoins, elles vous présentent les points essentiels pour effectuer une livraison de logiciel.
Les Tags et Branches vous apportent essentiellement un moyen de revenir en arrière (et modifier), et mettre à jour CVS avec vos modifications.
L’utilisation de branches peut porter à confusion au début, mais accrochez vous, et apprenez à maitriser les concepts et commandes.
Une fois ceux-ci acquis, vous les utiliserez constamment pour effectuer vos gestion de versions.
Une dernière chose : de nombreuses idées présentées ici sont issues du livre open Source Development with CVS, by Karl Fogel et Moshe Bar.
Je vous recommande vivement de l’acquérir et de plus, il est gratuitement disponible sur cvsbook.red-bean.com
D’autres Interface pour CVS
En conclusion de cet article, jetons un rapide coup d’oeil à quatre interfaces graphique pour CVS sur Mac OS X.
Mon but ici est de vous donnez un aperçu de ces outils et que vous sachiez que de telles interfaces existent.
Je vous encourage à tester chaque programme et voir si il s’intègre bien à votre processus de développement et vous aident à être plus productif.
Vous ne pouvez jamais devinez quand vous découvrirez quelque chose qui améliore la productivité et le facteur fun du développement.
BBEdit
Depuis les débuts du Macintosh, j’ai toujours été un grand fan de BBEdit.
Si vous n’avez jamais utilisé BBEdit, arrêtez-vous maintenant, allez sur le site web, et téléchargez la démo.
Après l’avoir utilisé quelque fois, vous serez accro.
BBEdit a toujours été un très bon éditeur avec de nombreuses fonctionnalités pour les tâches de développement logiciel et d’édition de texte.
Ce qui est sûrement le plus utile est l’aide au développement avec la coloration syntaxique, l’intégration avec la ligne de commande, le support interne de Perl, Python et le script shell, l’intégration avec Project Builder et d’autant plus important pour cet article, l’intégration avec CVS.
Pour utiliser BBEdit avec CVS, vous pouvez utiliser la même astuce utilisée avec Project Builder, que vous avez lancé depuis la ligne de commande avec la commande open.
Par exemple, allez au répertoire de MyPing (cd) et tapez la commande suivante (assurez-vous que les outils en ligne de commande de BBEdit sont installés) :
% bbedit PingController.mLe menu CVS de BBEdit vous permet d’exécuter des commandes CVS.
Comme vous pouvez le voir ci-dessous, BBEdit en propose un grand nombre que vous connaissez déjà.
Il est également possible de configurer BBEdit et Projet Builder pour qu’ils travaillent ensemble. Une fois configurés, lorsque vous ouvrez un fichier dans Project Builder, ce fichier est chargé dans BBEdit. Quand vous sauvegardez le fichier, BBEdit indique à Project Builder de mettre à jour son statut.
MacCVSClientX
MacCVSClientX est un client CVS multithreadé gratuit pour Mac OS X et Mac OS (Classic).
Contrairement à Project Builder et BBEdit, MacCVSClientX n’est pas un environnement de développement ou un éditeur.
Il vous permet de visualiser des différences entre fichiers, des conflits, de gérer les ajouts et imports, et gérer l’historique des modifications des fichiers de votre projet.
Concurrent Versions Librarian
Concurrent Versions Librarian (CVL) est une interface pour CVS, qui intègre de nombreuses commandes CVS, y compris commit, update, tag, checkout, import, status, log, et gère les différences et les inspecteurs de tag.
Il utilise FileMerge d’Apple pour résoudre les conflits et vous permet d’interagir avec de multiples racines CVS.
CVL supporte aussi l’intégration avec Project Builder.
Si vous double-cliquez sur un fichier dans Work Area, CVL ouvrira le fichier dans Project Builder.
Vous pouvez effectuer de nombreuses commandes CVS en sélectionnant un fichier ou en cliquant sur le bouton droit sur un fichier ou en sélectionnant la commande depuis le menu CVL.
De plus, vous pouvez obtenir des informations sur un fichier par Tools->Inspector, y compris l’état du fichier, des informations de log, tags, et les différences.
Par exemple, pour obtenir des informations de log sur un fichier, sélectionner le fichier depuis la work area et choisissez Tools->Inspector->Logs.
LinCVS
Le dernier programme que nous regarderons est LinCVS.
LinCVS est une interface pour CVS cross-plateforme gratuite qui fonctionne sous Mac OS X, UNIX et Windows.
Le programme utilise la librairie Qt qui permet de créer des applications cross-plateformes à partir d’un code source unique.
Comme avec les autres programmes que nous avons vus, LinCVS gère la plupart des commandes CVS dont vous aurez besoin.
Pour les utilisateurs Mac OS X, LinCVS se lance depuis le Terminal ou en double-cliquant sur son icône.
Pour accéder à la racine CVS distante, j’utilise la même technique qu’avec Project Builder, que je lance depuis le shell avec la commande open.
Ensuite, je crée un nouveau profil, j’ai entré mes information CVS, et effectué un check out du projet MyPing.
Si vous développez des applications cross-plateformes, et que vous recherchez une bonne interface pour CVS, LinCVS vaut vraiment le détour.
Conclusion
Ceci conclut notre étude du contrôle de version sous Mac OS X via CVS et Project Builder.
J’espère que cette série d’articles vous a convaincu que le contrôle de version est une part importante de tout projet de développement logiciel et que l’intégrer au processus de développement est relativement transparent.
Textes originaux en anglais sur O’Reilly : Version Control on Mac OS X, Part 3 par Kevin O’Malley
Chargement
Commentaires récents