Bonnes pratiques sous Subversion
19 09 2007
Un gestionnaire de source est toujours la 1ère étape dans une démarche d’industrialisation.
Si vous n’avez pas vos sources dans un référentiel au moment où vous lisez ces lignes, arrêtez-vous de suite et prenez le temps de le faire (Subversion).
La gestion de ce référentiel implique une certaine rigueur et une liste « officielle » de bonnes pratiques vient d’être publié sur le site de Subversion. J’ai repris les idées les plus intéressantes :
- Utiliser une arborescence propre
Quand on initialise le référentiel, il est facile de créer une arborescence inefficiente qu’il faudra supporter jusqu’au bout du projet. La recommandation officielle est de créer les trois dossiers : /trunk, /branches et /tags.
- Archiver des modifications fonctionnelles
Lorsque vous archivez vos modifications sur le source, celles-ci doivent être cohérentes et former un tout. Cela permettra un meilleur suivi des changements. De plus, ce changement pourra plus facilement être lié à un bug ou autre…
- Relier le gestionnaire des bugs
Il est fondamental de pouvoir être capable de relier un changement du source avec une « unité de travail ». Cette unité pouvant être un bug, une demande de changement, une évolution, etc. De ce fait, il faut associer à chaque archivage l’ID de l’item traité.
- Patient avec les gros fichiers
Subversion sait gérer le versionning des fichiers binaires mais de manière générale, manipuler ces fichiers engendrent des problèmes de latence qui peuvent devenir important. En effet, les fichiers sont copiés plusieurs fois en plusieurs endroits (dans le temp, dans le working local, …) et sur de gros transferts, le développeur devra être patient.
- Savoir quand créer une branche
Point critique, car la création d’une nouvelle branche n’est l’affaire que d’un compromis. Compromis entre l’avantage de pouvoir écrire du code non dépendant de la branche principale avec l’inconvénient de devoir un jour fusionner la branche avec le code principal.
A cette problématique, la réponse est question de contexte. Néanmoins trois stratégies se distinguent :
- Aucune branche : Demande une forte discipline de la part des développeurs qui devront minimiser les risques de « break » du build.
- Branche pour toute évolution : Chaque évolution est micro-managée et validée avant intégration dans la branche principale. Adapté aux gros projets possédant une équipe dédiée aux builds.
- Branche pour les dev > 10j. Il s’agit de définir une limite où les développements qui nécessitent plus de temps se feront dans une branche à part. Pour information, c’est la technique employée dans l’équipe de développement du serveur Subversion.
Comme toujours, beaucoup de ces pratiques sont l’œuvre du bon sens. Si vous possédez également des techniques intéressantes, n’hésitez pas à partager 😉
Je hais wordpress qui vire le cache des formulaires … même sous firefox … je t’avais fait un méga commentaire de la mort qui tue … et bah tu viens de le perdre ! :p
Bon, finalement, tu t’en sors bien rodrigo … vive ethereal 😉
Je te copie colle mon commentaire (et un double commentaire, un !)
rooo… t’as pas parlé de la méthode qui évite les « mais quel est le boulet qui a commité son répertoire de binaires ! » 🙂
Une autre pratique un peu plus sioux et qui rejoint la pratique « un ensemble de fichier pour un commit cohérent » : lorsqu’on « s’amuse » à « formater » (ie bien indenter, tout joli tout bô) le source … autant le faire pour plein de classes d’un seul coup et le dire à tout le monde de manière à ce qu’ils updatent le plus vite possible (parce que généralement, 80% des lignes sont impactées, et on ne voit plus les diff entre fichiers).
Moi d’une manière générale, une fois qu’un fichier a été commité, et même si j’ai vraiment le ctrl+shift+f facile (eclipse powa), j’essaie le moins possible de formater mon code « après le premier commit » (bouh ! pas bien).
C’est rigolo, puisque sur liferay, cette pratique allait tellement loin qu’il y avait carrément une tâche ant pour formater tout le code source (une sorte de ctrl shift f géant :)). Ca peut être pas mal sur un projet d’automatiser (genre une fois par semaine) une telle tâche qui checkout / format / commit toutes les sources du projet =)
Pour le control shift F, je n’aurais qu’une réponse :
Je programme en Control-Shift-F
Et pour la tâche ant, je confirme que c’est pas mal. Après attention à pas devenir un nazi du code…
Savoir quand créer un tag/label
Tagger une version qui est livrée à un client peut être intéressant afin de pourvoir reconstruire le projet et de retrouver dans le même état que lors de la livraison. Cela peut se faire en indiquant un numéro de revision ou bien une date.
Utile pour figer l’état d’une livraison.
Utile pour figer l’état d’une itération, contenant un périmètre fonctionnel bien identifié.
Utile pour figer l’état d’une version de développement, contenant un périmètre fonctionnel bien identifié.