Groupe Eyrolles, 2006, ISBN :

Transcription

1 Groupe Eyrolles, 2006, ISBN :

2 2 Qu est-ce que le contrôle de versions? Le concept du contrôle de versions est assez simple. Il s agit d enregistrer toutes les révisions de ce qui peut être codé ou rédigé lors du développement d une application. Malheureusement, la confusion s est vite installée entre les termes utilisés pour les différents composants du système de versions. Nous commencerons donc par définir les termes employés dans cet ouvrage, tout en indiquant les autres terminologies que vous pourrez trouver, en français ou en anglais. Cette dernière langue est en effet fréquemment utilisée car elle correspond aux commandes employées dans la majorité des systèmes de contrôle de versions. Un dépôt central, ou référentiel Nous avons jusqu ici présenté le système de contrôle de versions comme «l endroit où enregistrer ce que vous produisez», sans précision. En fait, le cœur du système est appelé dépôt (repository), ou encore référentiel. Le dépôt contient, pour presque tous les systèmes de contrôle de versions, la copie de référence de toutes les versions des fichiers de votre projet. Il peut prendre la forme d une base de données, d un ensemble de fichiers normaux ou de la combinaison des

3 8 Pratique du développement collaboratif avec Subversion deux approches. Il s agit dans tous les cas d un élément essentiel de votre gestion de versions et doit à ce titre se trouver sur un ordinateur sécurisé et fiable, régulièrement sauvegardé. Un serveur et des clients distants Avant que les systèmes de versions ne prennent en charge les opérations réseau, les utilisateurs devaient travailler sur le même ordinateur que le dépôt ou, a minima, accéder directement à son système de fichiers. Il était donc difficile de travailler depuis des sites distants et sur des systèmes d exploitation ou des types de machines variés. Cette lacune a été corrigée : de nos jours, vous pouvez accéder à vos données par le biais du réseau. Le dépôt fait office de serveur et les outils de contrôle de versions en sont autant de clients. Le travail devient donc beaucoup plus flexible : les développeurs peuvent se trouver à n importe quel endroit du monde disposant d une connexion réseau et néanmoins accéder à tout le code du projet et à son historique. Ceci se fait en toute sécurité : vous ouvrez à vos collaborateurs l accès Internet à votre dépôt sans que vos concurrents puissent atteindre votre précieux code source. Différentes déclinaisons de l accès réseau Deux définitions du terme «accès réseau» cohabitent chez les concepteurs de systèmes de contrôle de versions. Pour certains, cela signifie simplement un accès aux fichiers d un dépôt via des lecteurs réseau partagés (comme les partages Windows ou les montages NFS). Pour d autres, il s agit d une architecture client-serveur : les clients travaillent avec un dépôt serveur à travers un réseau. Ces deux solutions peuvent fonctionner (la première est cependant assez difficile à concevoir correctement si le mécanisme sous-jacent ne permet pas de verrouiller les fichiers). L utilisation de l un ou l autre de ces systèmes dépend de vos contraintes en termes de déploiement et de sécurité. Si vous utilisez un système basé sur des lecteurs réseau et si vous devez y accéder depuis l extérieur, il faut vous assurer de pouvoir atteindre les données. C est entre autres à cela que servent les VPN (Virtual Private Networks, réseaux privés virtuels), mais toutes les entreprises n en disposent pas. Subversion, lui, est basé sur une architecture client-serveur pour les accès distants. La possibilité de travailler hors ligne Une question se pose immédiatement : que se passe-t-il lorsque vous devez développer mais ne disposez pas d un accès réseau au dépôt? La réponse simple est : «ça dépend». Certains systèmes de contrôle de versions n envisagent pas que vous puissiez être déconnecté du dépôt central lorsque vous travaillez. D autres, dont Subver-

4 Qu est-ce que le contrôle de versions? CHAPITRE 2 9 sion, sont plus souples. Modifier le code dans l avion sur un portable et le re-synchroniser en arrivant à l hôtel ne pose pas de problème. Le mode connecté/ déconnecté est un élément clé pour le choix d un système de contrôle de versions. Assurez-vous que celui que vous choisissez correspond à vos méthodes de travail. ALTERNATIVE Dépôts multiples décentralisés Certains systèmes utilisent des dépôts multiples en lieu et place d un dépôt central unique. Les développeurs s échangent des ensembles de modifications entre les différents dépôts. Ces systèmes décentralisés sont très populaires lorsque de nombreux développeurs doivent travailler de manière semi-autonome. L exemple le plus célèbre est Bitkeeper a, le système utilisé jusque récemment pour le développement du noyau Linux. Arch et SVK en sont d autres exemples. Leur utilisation et le style de développement associé sont très différents et nous n en parlerons pas plus dans cet ouvrage. a. Il a été remplacé par un autre outil, Git, développé spécialement suite à des problèmes de licence de Bitkeeper. Quels éléments enregistrer sur le dépôt? Il faut enregistrer tous les éléments importants d un projet, mais quels sont-ils? Bien évidemment, il faut enregistrer les fichiers de code source que vous utilisez pour compiler votre projet, qu il s agisse de Java, C#, Ruby ou de n importe quel autre langage de programmation. D ailleurs, certains utilisent le terme «systèmes de contrôle de codes sources» pour désigner les systèmes de contrôle de versions. Toutefois, bien d autres éléments, souvent oubliés, doivent également être enregistrés sous contrôle de versions. Par exemple, il peut s agir du script build.xml utilisé par Ant si vous travaillez en Java, car sans lui vous aurez du mal à compiler l application. De même, de nombreux projets utilisent des métadonnées concernant leur configuration ; celles-ci ont également leur place dans le dépôt. Il en est de même pour les scripts de production d images pour les CD-Rom, pour les jeux de données de tests du département qualité, etc. RÈGLE D OR Éléments à enregistrer absolument Il suffit en fait de se poser la question «Si je ne dispose pas d une version à jour de tel fichier, est-ce que je peux construire, tester et livrer l application?». Si la réponse est «non», le fichier en question doit être enregistré dans le dépôt. En plus de ce qui est nécessaire pour effectuer une livraison de votre projet, nous vous conseillons d enregistrer dans le système de contrôle de versions tout ce qui, de manière générale, est utile au projet. Cela inclut en particulier la documentation (à la

5 10 Pratique du développement collaboratif avec Subversion fois celle qui est destinée aux clients et celle à l usage des développeurs), certains courriers électroniques importants, les comptes-rendus de réunions, les informations que vous trouvez sur le Web tout ce qui, d une manière ou d une autre, contribue au projet. Qu en est-il des fichiers annexes générés? Si nous enregistrons tout ce qui est nécessaire à la compilation du projet, faut-il y ajouter les fichiers générés? Par exemple, nous pouvons lancer JavaDoc pour produire la documentation de l API de notre arborescence de source. La documentation doit-elle dans ce cas être enregistrée dans le système de contrôle de versions? La réponse est «non». Si un fichier peut être reconstitué à partir des autres, l enregistrer dans le dépôt n est que de la duplication de données. Ce n est pas tant un problème de place disque qu une question de contrôle sur ce qui se passe : si nous modifions le code source et oublions de mettre la documentation à jour dans le dépôt, elle ne correspondra plus au code source qui s y trouve. Dans ce cas, ne gardons que la source des informations, en l occurrence le code. On peut appliquer cette règle à la plupart des fichiers générés. En pratique néanmoins, ces fichiers peuvent être délicats à regénérer. Peut-être ne possédez-vous qu une seule licence pour l outil qui produit un fichier donné dont tous les développeurs ont besoin. Un fichier peut également nécessiter des heures de génération. Les enregistrer dans le dépôt n est alors pas une si mauvaise idée mais il faut penser à les garder à jour par rapport à ce dont ils sont issus. Des copies de travail locales pour manipuler des fichiers Le dépôt contient tous les fichiers de notre projet, mais cela ne nous aide pas en soi à ajouter des fonctionnalités à notre application. Nous avons besoin des fichiers là où nous pouvons les modifier. C est ce que l on appelle une copie de travail (working copy). On trouve dans la copie locale tout ce qui est nécessaire à un développeur pour faire son travail. Lorsque le projet n est pas d une taille démesurée, il s agit souvent d une copie de l ensemble du code et des fichiers annexes. Pour des projets plus ambitieux, les développeurs peuvent n avoir à se préoccuper que d une partie du code, ce qui leur économise du temps à la compilation et aide à la modularisation générale du projet. La copie de travail est alors parfois appelée «répertoire de travail» (working directory) ou «espace de travail» (workspace).

6 Qu est-ce que le contrôle de versions? CHAPITRE 2 11 Récupérer une première copie (checkout) Tâchons d obtenir notre première copie de travail depuis le dépôt. Les systèmes de contrôle de versions disposent de différents noms pour cette opération, mais le plus courant (et celui que Subversion utilise) est l extraction (checking out), ou encore la récupération. Lorsque vous extrayez une version du dépôt, vous faites des copies locales des fichiers dans votre espace de travail. Il faut impérativement extraire les fichiers, même si vous travaillez sur l ordinateur hébergeant le dépôt. Ce dernier doit être traité comme une boîte noire : vous ne devez vous soucier ni de l endroit où il est, ni de la manière d y accéder. Extraire les fichiers vous fournit une copie à jour des fichiers que vous avez demandés dans une arborescence de répertoires qui correspond à celle du dépôt. On peut aussi exporter les fichiers du dépôt ce qui est une opération légèrement différente de la récupération dont nous venons de traiter. Après une exportation, vous n obtenez pas une copie de travail, mais seulement un instantané des fichiers dans le dépôt. Cela peut être utile pour faire un paquetage du code en vue de sa distribution. Propager ses modifications Lorsque vous travaillez sur un projet, vous modifiez votre copie de travail. De temps en temps, il faudra enregistrer ces modifications dans le dépôt. On appelle cela propager (committing) ou valider les modifications dans le dépôt. Actualiser sa copie de travail Vous n êtes bien sûr pas le seul à travailler et faire des modifications. Les autres membres de votre équipe propagent aussi leurs changements dans le dépôt. Votre copie locale ne reflète pas cet état elle n est pas mise à jour automatiquement à chaque évolution du dépôt. Il faut le demander explicitement au système de contrôle de versions c est l opération d actualisation (update) ou de mise à jour. Vous recevez ainsi la dernière version des fichiers du dépôt. De même, lorsque vos collègues actualisent leur copie locale, ils reçoivent vos dernières modifications. VOCABULAIRE Précisons que certains utilisent indifféremment les termes d actualisation et d extraction car ils estiment extraire les derniers changements.

7 12 Pratique du développement collaboratif avec Subversion Il s agit d un vocable courant que nous utiliserons de temps à autre dans ce livre. La figure 2-1 montre ces différentes interactions. Figure 2 1 Travailler à plusieurs : dépôt et les copies de travail Nous voyons apparaître un problème potentiel : que se passe-t-il si un collègue et vous-même décidez de modifier le même fichier source au même moment? Cela dépend du système de contrôle de versions que vous utilisez, mais tous disposent de méthodes pour gérer la situation. Nous en parlerons plus en détail dans la section Options de verrouillage. Organisation en projets, répertoires et fichiers Jusqu ici, nous avons parlé d enregistrer des éléments sans expliquer comment ces éléments sont organisés. L élément de base de la plupart des systèmes de contrôle de versions est le fichier 1 : chaque fichier de votre projet est enregistré par son nom dans le dépôt. Mais cette organisation ne convient pas lorsque le projet se compose de centaines ou de milliers de fichiers et une entreprise dispose souvent de dizaines de projets. C est pour cela que presque tous les systèmes de contrôle de versions permettent de structurer le dépôt. Prenons l exemple d une application de commande de livres en ligne. Au niveau le plus haut, votre travail est divisé en projets. Tous les fichiers nécessaires au déploiement de l application seront enregistrés dans un projet du dépôt et, si vous le désirez, vous pouvez récupérer celui-ci intégralement sur votre disque dur. Au niveau immédiatement inférieur, le projet est divisé en différents modules indépendants. Dans 1. Dans certains environnements de développement, l'élément atomique est la méthode d un code source, mais ils sont relativement peu courants.

8 Qu est-ce que le contrôle de versions? CHAPITRE 2 13 notre exemple, une équipe travaille peut-être sur le traitement des cartes bancaires et une autre sur la prise en charge des commandes. Les personnes impliquées dans le sous-projet «carte bancaire» n ont pas nécessairement besoin de tout le code source du projet pour travailler. Lorsqu ils extraient le code, ils ne veulent en fait récupérer que ce qui les concerne. Dans le cas de Subversion, le dépôt est organisé en répertoires. Un projet est un répertoire au plus haut niveau et les modules et sous-modules sont des sous-répertoires de votre projet. Cette organisation peut suffire pour les projets simples. Pour les projets plus complexes, vous disposez de modules externes (externals) : définir un module externe vous permet d ajouter un autre dépôt Subversion dans un répertoire de votre projet. Remarque pour les utilisateurs de CVS L organisation de Subversion en répertoires correspond à peu près à la notion de modules CVS. Les modules externes correspondent aux «alias de modules». L organisation en répertoires est tout aussi puissante que l organisation en modules et bien plus simple à comprendre pour la majorité des gens. Nous parlerons plus en détail de cette approche «tout est répertoire» au chapitre 7, Organiser votre dépôt. Le rôle des versions Pour l instant, nous n avons parlé que d enregistrer et obtenir des fichiers dans et depuis un dépôt. Qu en est-il des versions? En fait, le dépôt ne se contente pas de stocker les différents fichiers qui lui sont ajoutés ; il enregistre toutes les versions qui y sont propagées. Si vous extrayez un fichier, le modifiez et propagez vos changements, le dépôt contiendra la version originale et la version modifiée. Les systèmes de contrôle de versions ne gardent pour la plupart que les différentiels entre les versions et non leurs copies complètes. Ainsi Subversion enregistre complètement la dernière version en date et quelques révisions soigneusement choisies. C est un bon compromis entre la taille du répertoire sur le disque et la rapidité des mises à jour et des récupérations. Numérotation des versions On trouve deux approches pour la numérotation des versions : dans un cas ce sont les fichiers qui sont repérés, dans l autre c est tout le dépôt. Lorsque les fichiers sont

9 14 Pratique du développement collaboratif avec Subversion numérotés, la première révision du fichier est nommée 1.1, la suivante 1.2 et ainsi de suite. Par exemple, si vous avez les versions 1.2 de Noeud.cs et 1.6 de Graphe.cs, propager une modification de Noeud.cs l amènera à sa version 1.3 tandis que Graphe.cs restera à 1.6. Lorsque la numérotation s applique au dépôt, le dépôt complet commence à la révision 0 et propager une modification passe la révision de l ensemble à 1, puis 2, et ainsi de suite. Dans cette configuration, on parlera plutôt de «Panel.java de la révision 7» que de «la révision 7 de Panel.java». C est le choix effectué par Subversion. Celui-ci s avère extrêmement pratique lorsqu il s agit de faire référence à des modifications une fois qu elles ont été validées. La section Correctifs de bogues simples, dans le chapitre 8, expliquera comment utiliser les numéros de révision pour fusionner les corrections de bogues entre les branches. Remarque pour les utilisateurs de CVS CVS numérote les fichiers plutôt que le dépôt ; certaines personnes se basent sur le numéro de version d un fichier pour estimer l activité du fichier en question. La numérotation du dépôt utilisée par Subversion ne permet pas cela ; on utilise la commande svn log pour afficher les modifications dans l historique. La figure 2-2 illustre le principe de numérotation appliquée au dépôt. Elle représente trois fichiers : Trains.java, Graphe.java et Noeud.java. Nous propageons d abord une modification dans Graphe.java, le dépôt passe donc à sa révision 2. Si nous modifions Trains.java et Noeud.java, le dépôt passe en révision 3. La révision de Graphe.java est également 3, même si ce fichier n a pas été modifié dans cette révision (les modifications des fichiers sont représentées par les changements de symboles dans les cases de la figure 2-2). Figure 2 2 Numérotation des révisions dans le dépôt Par conséquent, les numéros de révision de Subversion ne sont pas d une grande aide pour connaître l état d un fichier ou groupe de fichiers donné 2. Si vous êtes habitué à une numérotation par fichier, il se peut que vous soyez perdu en voyant votre dépôt passer d un numéro à l autre sans que vous n ayez rien modifié. Cela a plus de sens si

10 Qu est-ce que le contrôle de versions? CHAPITRE 2 15 vous réalisez que la numérotation s applique à toutes les validations et non aux vôtres seules. Enregistrement des versions L enregistrement des révisions est extrêmement puissant. Le système peut s en servir pour récupérer une version donnée d un fichier, obtenir le code source d une application exactement tel qu il était un mois avant ou encore vous dire ce qui a changé dans un fichier donné entre les révisions 7 et 9. Cela peut également servir à annuler des erreurs. Si vous vous apercevez en fin de semaine que vous vous êtes engagé dans une impasse, vous pouvez annuler vos modifications et revenir au code du lundi matin. Marquer l état du projet à un instant donné La numérotation des versions est très pratique, mais en général les humains se souviennent mieux d un nom tel que «PréLivraison2» que d un numéro tel que «r347». Vous pouvez assigner un nom à un groupe de fichiers (ou un répertoire ou un projet entier) à une date donnée grâce à une marque (tag). Si vous avez nommé un groupe de fichiers «PreLivraison2», vous pouvez les récupérer avec cette même marque. Les marques permettent une bonne gestion des événements de la vie du projet. Nous les utiliserons beaucoup dans cet ouvrage. Nous parlerons des marques et des branches (qui feront l objet de la prochaine section) au chapitre 8. Créer plusieurs branches Un problème fréquent : gérer le code à livrer En temps normal, la base de code est commune à tous les développeurs du projet (même s ils travaillent probablement sur différentes parties de cette base). Ceux-ci récupèrent du code, le modifient dans leur copie de travail et propagent leurs modifications, le tout étant partagé. Cette base de code s appelle le tronc commun (trunk) 2. Cette méthode est de toutes manières assez aléatoire. Une seule révision peut concerner toutes les lignes d un fichier il est bien plus sûr d utiliser les fonctions de navigation de votre système de gestion de versions pour savoir à quel point vos données ont été modifiées.

11 16 Pratique du développement collaboratif avec Subversion et est illustrée par la figure 2-3. Dans cette figure (et celles qui suivent), l axe de temps va de gauche à droite. La ligne la plus épaisse représente la progression du tronc commun au cours du développement. Les développeurs en extraient le code et y propagent leurs modifications. Figure 2 3 Un tronc commun simple Supposons maintenant que l heure de la livraison approche : nous sortons du fonctionnement normal du projet. Une partie de l équipe s occupe des bogues de dernière minute ; il leur faut pour cela du code stable car ajouter une fonctionnalité (prévue pour la livraison suivante) est source potentielle de nouveaux bogues. Une première solution est d arrêter tout développement pendant la préparation de la livraison ce qui revient à mettre en chômage technique le reste de l équipe. On peut aussi envisager de copier le code source sur une autre machine et demander à l équipe de livraison de ne travailler que sur cette machine. Qu adviendra-t-il alors des modifications qu ils font? Comment en garder trace? S ils trouvent des bogues dans le code livré qui sont également présents dans le tronc commun, comment y réintégrer leurs correctifs? Et une fois que le logiciel a été livré, comment réparer les bogues signalés par les clients? Comment être sûr que le code dont nous disposons est bien le même que celui que nous avions livré? La solution : utiliser des branches Il est bien plus judicieux d utiliser la gestion des branches proposée par les systèmes de contrôle de versions. Lorsque l on crée une nouvelle branche, on sépare l avenir du code en deux possibilités. Revenons à notre exemple : l équipe doit livrer une nouvelle version du produit. Jusqu ici, tout le monde a travaillé dans le tronc commun, la base de code montrée en figure 2-3. Les développeurs qui s occupent de la livraison veulent s isoler de ce tronc commun et créent une branche dans le dépôt. Désormais, et jusqu à la livraison, ils travailleront uniquement dans cette branche. Une fois que l application sera livrée, la

12 Qu est-ce que le contrôle de versions? CHAPITRE 2 17 branche restera active : on y placera les corrections des bogues signalés par les clients. Cela est illustré à la figure 2-4. Figure 2 4 Tronc commun et branche de livraison Une branche se comporte presque comme un dépôt complètement différent : les gens qui l utilisent voient le code qu elle contient et travaillent indépendamment des gens qui utilisent une autre branche ou le tronc commun. Chaque branche a son propre historique et trace les modifications indépendamment du tronc commun à partir du moment où les branches se différencient. C est exactement le comportement désiré lors d une livraison. Les développeurs qui travaillent sur la livraison disposent d une base de code stable à peaufiner et le reste de l équipe peut continuer à travailler sur la base de code principale. De plus, lorsque les clients signalent un problème, le code sera disponible dans la branche de livraison, ce qui facilite la correction des bogues sans pour autant inclure du code récent du tronc commun. Gestion des branches Les branches sont gérées elles aussi sous forme de répertoires dans Subversion : vous pouvez créer une branche en copiant le tronc commun dans un nouvel emplacement. En interne, le mécanisme de copie de Subversion est dit «paresseux» (lazy copies), ce qui améliore son efficacité. Lorsque vous copiez un fichier ou un répertoire, Subversion fait un lien vers l original. Il enregistre ensuite uniquement les modifications par rapport à cet original. De cette manière, Subversion peut copier des arborescences lourdes rapidement et sur très peu d espace disque. Il vaut mieux utiliser les branches avec parcimonie. Ce mécanisme est certes fort pratique lorsqu il s agit de ne pas mettre tous vos œufs dans le même panier mais la fusion entre les branches peut vite devenir coûteuse : il faut fusionner plusieurs bases

13 18 Pratique du développement collaboratif avec Subversion de développement sans en oublier. Il est à noter que si vous créez de nombreuses branches, en particulier pour paralléliser différentes approches de développement plutôt que pour préparer des livraisons, c est peut-être le signe qu il y a un problème. Dans ce livre, nous décrirons un schéma simple pour répondre à vos besoins sans ajouter de complexité inutile. ATTENTION Et des branches de branches? En théorie, on peut créer des branches de branches. En pratique, il est rare d y recourir. Nous avons rencontré de nombreux développeurs qui ont abandonné définitivement l usage de branches après une mauvaise expérience due à un schéma de branches trop complexe. Fusionner des branches Plusieurs branches d un dépôt peuvent cohabiter sur le même ordinateur, dans des répertoires différents. Un développeur travaillera ainsi en parallèle sur le tronc commun et sur les correctifs de bogues de la branche de livraison. Les systèmes de contrôle de versions permettent aussi de fusionner deux branches. Si vous corrigez un bogue dans la branche de livraison et si le même bogue est présent dans le tronc commun, vous demanderez au système de contrôle de versions d appliquer au tronc commun les changements que vous avez effectués dans la branche. Vous pouvez aussi fusionner plusieurs branches de livraison. Cela évite la plupart des opérations de copier-coller entre les différentes versions. Nous parlerons de la fusion plus en détail dans la suite. Les différents types de verrouillage Supposons que deux développeurs travaillent sur le même projet. Ils ont tous les deux récupéré les fichiers du projet dans leurs espaces de travail respectifs et ils veulent tous deux modifier leur copie de Fichier1.java. Que va-t-il se passer lorsqu ils valideront les modifications? Dans le pire des cas, le système de contrôle de versions accepte les modifications du premier développeur, puis celles du second. Comme celui-ci n a pas intégré les premières modifications, ces dernières sont alors perdues. Pour éviter cela, les systèmes de contrôle de versions disposent d un processus de résolution de conflits. Il en existe principalement deux types.

14 Qu est-ce que le contrôle de versions? CHAPITRE 2 19 Verrouillage strict Tous les fichiers extraits depuis le dépôt sont marqués en lecture seule. Vous pouvez les lire et compiler votre application mais vous ne pouvez pas les modifier. Pour cela, il faut demander la permission au dépôt. Si personne d autre n édite le fichier, le dépôt vous accorde cette permission en écriture sur votre copie locale. Si quelqu un d autre réclame le fichier pendant cet intervalle de temps, la permission lui sera refusée. La copie ne sera disponible pour les autres membres de l équipe que lorsque vous aurez terminé et propagé vos modifications. Votre copie locale revient alors en lecture seule. Verrouillage optimiste Le second type de résolution de conflits est souvent désigné par le nom de «verrouillage optimiste», même s il ne s agit pas à proprement parler d un verrouillage. Dans ce cas, tous les développeurs peuvent modifier tous les fichiers qu ils ont extraits. En revanche, le dépôt ne permet pas de propager un fichier qui n est pas à jour par rapport à la version du dépôt : vous devez d abord actualiser votre copie locale pour inclure les dernières modifications avant de propager les vôtres. Toute l intelligence du système réside dans le fait que, plutôt que d effacer vos modifications en les remplaçant par celles du dépôt, il essaie de fusionner les deux jeux de modifications. Considérons par exemple le fichier Fichier1.java : public class File1 { public String getname(){ return "Toto"; } public int getsize() { return 42; } } Les deux développeurs extraient tous deux ce fichier. Le premier modifie la ligne 3 : return "TOTO"; et propage cette modification. La copie du deuxième développeur est alors périmée, sans que celui-ci en soit conscient. Il change alors la ligne 6 pour retourner 99 et non 42. Lorsqu il tente de propager cette modification, le dépôt lui indique que sa copie n est pas à jour : il doit fusionner les modifications apportées à la copie de

15 20 Pratique du développement collaboratif avec Subversion dépôt. Cela correspond à l étoile marquée «DÉSYNCHRONISATION» de la figure 2-5. Figure 2 5 Deux développeurs modifient le même fichier mais le conflit est résolu par une fusion. Les deux modifications touchent des parties différentes du fichier ; le système de contrôle de versions met à jour la ligne 3 de la copie locale du second développeur sans toucher au reste. Ainsi, les deux versions sont fusionnées sans problème. Le verrouillage optimiste peut vous paraître téméraire puisque plusieurs personnes peuvent travailler sur les mêmes fichiers en même temps. C est souvent ce que craignent les gens qui n ont jamais essayé de le mettre en pratique : ils estiment que cela ne peut pas marcher et refusent de travailler avec un système de contrôle de versions qui ne permet pas un verrouillage strict des fichiers.

16 Qu est-ce que le contrôle de versions? CHAPITRE 2 21 Un conflit peut arriver Que se serait-il passé s ils avaient tous deux modifié la ligne 3 de manière différente? De la même façon, le dépôt aurait signalé au deuxième développeur que sa copie locale n était plus valable. En revanche, lors de la mise à jour, le système ne sait pas quelle modification garder : nous sommes en présence d un conflit. Un avertissement est indiqué dans sa copie du fichier source. Il faudra le résoudre à la main et probablement discuter de la raison pour laquelle ils travaillaient tous deux sur la même ligne de code. En fait, le verrouillage strict apporte plus d ennuis que de bénéfices. Les conflits dans un système à verrouillage optimiste (comme Subversion) sont finalement assez rares. Les membres d une équipe donnée travaillent en général sur des parties différentes du code et les collisions ne sont pas très fréquentes. S ils doivent vraiment travailler sur le même fichier, c est souvent sur des portions de code différentes. Dans un système de verrouillage strict, il faudrait attendre que l autre personne ait terminé avant de pouvoir prendre la main sur le fichier. Ce problème ne se pose pas lorsqu on utilise un système de verrouillage optimiste. Nous avons testé les deux systèmes : pour la très grande majorité des gens, le système de verrouillage optimiste est le plus intéressant. Contrôle de versions ou gestion de configuration Il est possible que vous entendiez parler de systèmes de gestion de configuration (configuration management ou CM) ou de gestion de configuration logicielle (software configuration management, SCM). Ceux-ci peuvent ressembler à première vue à du contrôle de versions, ce qui est en grande partie vrai. En effet, la gestion de configuration s appuie largement sur un bon système de contrôle de versions. Cela n en est cependant pas le seul aspect. La gestion de configuration est une branche du génie logiciel qui vise à obtenir des livraisons de logiciel précises et reproductibles. La partie technique peut en être assurée par un système de contrôle de versions, mais ce travail nécessite de nombreuses interventions humaines pour vérifier que rien n a été oublié. Si la gestion de configuration consiste en l identification des éléments à ne pas oublier pour la livraison, le système de contrôle de versions permet d enregistrer cette identification. La gestion de configuration est un vaste sujet que nous ne pouvons pas traiter dans cet ouvrage. Si vous désirez en savoir plus à ce sujet, le livre Software Configuration Management Patterns : effective teamwork, practical integration (de Sephan P. Berczule et Brad Appleton, Addison-Wesley, 2003) vous fournira bien plus de détails. Pour le moment, voyons comment utiliser les systèmes de contrôle de versions pour gérer notre travail. Les chapitres suivants s articulent autour de l utilisation d un système particulier, Subversion.

17 22 Pratique du développement collaboratif avec Subversion Mise en œuvre Le contrôle de versions présente des avantages évidents pour la gestion de projet ; pourtant, peu d équipes le mettent en œuvre. Pour certaines, c est le passage à la pratique qui pose problème : «créer une branche de livraison» est clair, mais la traduction en commandes Subversion l est nettement moins. D autres équipes partent dans l excès inverse et créent de splendides structures extrêmement complexes, ce qui rend le tout impossible à gérer au quotidien. Pour résoudre ces deux problématiques, nous présenterons à la fois une méthode simple pour organiser votre système de contrôle de versions et un ensemble de «recettes de cuisine» pour son usage quotidien. Essayez de ne pas trop vous en éloigner. Si vous estimez avoir besoin d un scénario que nous ne couvrons pas, réfléchissez-y à deux fois : ce n est peut-être pas nécessaire. Comme pour toutes les recettes de cuisine, celles-ci vous deviendront de plus en plus familières au fur et à mesure que vous les exécuterez ; vous pourrez alors commencer à faire d autres expériences. Évitez cependant de les mener dans un dépôt de production. Il vaut mieux tester le scénario que vous envisagez dans un dépôt dédié aux manipulations hasardeuses (comme celui que nous allons mettre en place au chapitre suivant) ne mettant pas en jeu l intégrité du système de production. Principes de base Le contrôle de versions doit être un des trois piliers pratiques que toute équipe projet doit maîtriser (les deux autres, le test unitaire et l automatisation de projets, sont couverts dans les ouvrages Pragmatic Unit Testing in Java with JUnit 3 et Pragmatic Project Automation : How to build, deploy and monitor Java applications 4 ). Toute équipe devrait utiliser un système de contrôle de versions, quelles que soient les circonstances et quel que soit ce qu elle produit. Pour que cela soit le cas, il faut que le système soit simple, transparent et léger. Simplicité. Elle implique que quelque chose qui doit a priori être simple l est effectivement. Propager toutes les modifications est une opération simple et courante ; cela doit donc se faire en une ou deux actions. Créer une livraison pour un client est plus complexe et moins courant : on peut se permettre d y consacrer plus d étapes, tout en gardant le processus le plus simple possible. 3. Andrew Hunt and David Thomas. The Pragmatic programmers, LLC, Raleigh, NC and Dallas, TX, Mike Clark. The Pragmatic programmers, LLC, Raleigh, NC and Dallas, TX, 2004.

18 Qu est-ce que le contrôle de versions? CHAPITRE 2 23 Transparence. Il nous faut savoir précisément ce que nous sommes en train de faire et pour quelle version du projet. Le développement logiciel ne supporte pas les devinettes... Légèreté. Aucune interférence ne sera admise avec le déroulement normal du travail. Éléments importants lors de l usage du contrôle de versions Voici un ensemble de règles générales à suivre lorsque vous utilisez un système de contrôle de versions : Assurez-vous avant de commencer que vous disposez d une connexion efficace et sécurisée à votre dépôt. Une fois que vous avez contacté le serveur Subversion, vous n utiliserez de façon quotidienne qu un petit nombre de commandes. Chaque projet de votre entreprise doit disposer de son propre répertoire dans le dépôt Subversion. Il faut pouvoir récupérer tout le code source d un projet donné à partir d un seul endroit. Si un projet contient des sous-composants autonomes ou partagés, ceux-ci devraient disposer d un projet propre et être inclus comme ressources externes dans d autres projets. Si du code de parties tierces intervient (fournisseurs ou projets libres), il doit être géré comme une ressource. Les développeurs doivent utiliser des branches pour séparer la base de code principale des autres bases, comme les branches de livraison et les expériences volumineuses. Il faut aussi utiliser les marques pour identifier les points saillants du développement, y compris les livraisons et corrections de bogues. Nous aborderons chacun de ces points dans les chapitres qui suivent.