Meilleures pratiques SVN - Travailler en équipe

Je commence avec SVN. Je connais les commandes de base et je comprends les principes de base. Je me demandais si quelqu'un avait des conseils ou des meilleures pratiques pour travailler avec Subversion dans un environnement d'équipe.

Je peux voir l'avantage d'ajouter des messages raisonnablement détaillés lors de la validation du code, mais y a-t-il d'autres choses que je devrais garder à l'esprit?

Merci pour toutes les bonnes réponses - elles ont beaucoup aidé.

Encouragez les commits fréquents. Les coéquipiers novices en contrôle de version peuvent ressentir le besoin de garder le code hors du référentiel jusqu'à ce que "cela fonctionne correctement". Apprenez à tout le monde à s'engager tôt et souvent à trouver les problèmes le plus tôt possible. Au lieu de conserver le code jusqu'à ce qu'il fonctionne, proposez à vos coéquipiers de créer des branches pour les fonctionnalités susceptibles de casser le tronc. Cela conduit à ...

Établissez une pratique de branchement et de marquage. En plus des branches pour les fonctionnalités, encouragez vos coéquipiers à utiliser des branches pour les corrections de bogues importants. Marquez les correctifs de bogues majeurs au début et à la fin du travail. Gérez les balises (et éventuellement les branches) pour les versions de production / qualité.

Établissez une politique pour le tronc et respectez-la. Un exemple pourrait être, «le tronc doit toujours se construire sans erreurs». ou "le tronc doit toujours réussir tous les tests unitaires". Tout travail qui ne peut pas encore répondre aux normes de coffre doit être effectué en succursale.

Ne pas valider les modifications de mise en forme avec les modifications de code

Si vous souhaitez restructurer l'espace blanc ( Control+ K+ D) d' un fichier géant , très bien. Validez la modification de mise en forme séparément de la modification logique réelle. Il en va de même si vous souhaitez déplacer des fonctions dans des fichiers. Commencez le déplacement séparément de l'édition réelle.

L'un des concepts clés sur lesquels je m'en tiens toujours est de valider ensemble les modifications de code associées . Le corollaire est de ne pas valider les modifications de code non liées dans le même commit . Cela signifie ne pas corriger 2 bogues dans un commit (sauf si c'est le même correctif), et ne pas commettre la moitié d'un correctif de bogue dans chacun des 2 commits. De plus, si j'ai besoin d'ajouter une nouvelle amélioration ou quelque chose à une partie non liée du système dont j'ai besoin pour un autre travail, je commets l'amélioration séparément (et d'abord). L'idée est que tout changement que quiconque voudrait éventuellement apporter seul (ou revenir seul) devrait être un commit séparé. Cela vous évitera des tonnes de maux de tête quand viendra le temps de faire des fusions ou de restaurer des fonctionnalités cassées.

Beaucoup de choses ont déjà été mentionnées, et en voici d'autres:

1. Si vous avez des fichiers que vous ne voulez pas dans le contrôle de code source (par exemple la configuration, les fichiers compilés, etc.), ajoutez-les à la liste des ignorés . De cette façon, vous remarquez tous les fichiers que vous oubliez d'ajouter en vous attendant toujours à une liste vide de fichiers apparaissant comme inconnus de SVN.

2. Ajoutez un événement post-commit qui enverrait un e-mail à votre liste de diffusion de développeur (ou un événement spécifique pour cette cible) concernant le changement engagé et idéalement le correctif correspondant.

3. Intégrez votre bug tracker afin que les références aux commits apparaissent sur les bogues / demandes de fonctionnalités avec des liens vers les diffs. Les traqueurs de bogues comme MantisBT le supportent.

4. Pensez à intégrer avec une intégration continue (par exemple CruiseControl.NET ), NAnt pour Build et NUnit / VS pour les tests unitaires. De cette façon, une fois qu'un utilisateur enregistre le code ou à un intervalle planifié, le code est compilé, les tests unitaires sont exécutés et le développeur obtient des commentaires sur le processus. Cela alerterait également le reste de l'équipe si le référentiel est cassé (c'est-à-dire qu'il ne se construit pas).

Eh bien, les bases:

• Créer des balises avant de démarrer le contrôle qualité sur une version
• Créez des balises avant les changements risqués (c'est-à-dire les gros refactors)
• Créez des branches pour les versions publiées afin de figer le code.
• Assurez-vous que les gens sachent mettre à jour avant de commencer à travailler sur un morceau de code et mettre à jour à nouveau avant de le valider.
• SVN permet plusieurs extractions du même fichier par différents utilisateurs. Assurez-vous que tout le monde résout tout conflit qui pourrait survenir.
• N'utilisez jamais le même compte SVN pour plus d'un utilisateur. Des choses terribles peuvent en résulter.

Les réponses que les gens donnent sont excellentes. Une grande partie de ceci est résumée dans la documentation utilisateur svn pour les meilleures pratiques pour SVN .
Répéter:

1. Configurez la structure de votre référentiel (vous devriez avoir la racine du projet avec le tronc, les branches et les balises en dessous)
2. Choisissez votre politique de branchement (branches privées, branches par jalon / version / bogue, etc.) et respectez-la - je recommanderais plus de branches plutôt que moins, mais pas besoin de branches privées
3. Choisissez votre politique en matière de balisage - plus de balises, mieux c'est, mais surtout décidez de vos conventions de dénomination
4. Choisissez votre politique en vous engageant sur le tronc - gardez le tronc aussi «propre» que possible, il devrait pouvoir être libéré à tout moment

Je voudrais résumer les meilleures pratiques auxquelles je m'en tiens:

1. Ne validez pas les binaires . Il doit y avoir un référentiel distinct pour les binaires, tels que Nexus , Ivy ou Artifactory .

2. Il devrait y avoir une structure de référentiel . Personnellement, j'utilise la structure de référentiel suivante:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. Utilisez une liste spécifique de types de branches . Ma liste est la suivante: expérimental , maintenance , versions , plates - formes , versions .
4. Utilisez des types de balises spécifiques : PA(pré-alpha), A(alpha), B(beta), AR(alpha-release), BR(beta-release), RC(release candidate), ST(stable).
5. Minimisez la nécessité de fusionner . Il devrait y avoir des règles lorsque la fusion est possible / encouragée et quand elle ne l'est pas.
6. Numérotation des versions . Il devrait y avoir une approche de numérotation de version établie à respecter. Habituellement, il est décrit dans un document tel que Plan de gestion de la configuration logicielle, il fait partie de la documentation de projet de haut niveau. Personnellement, j'utilise une approche complexe de numérotation de version. Selon cette approche, les versions ont les modèles suivants: Nxx (branches de maintenance / support), NMx (branche de version), NxK (construction), NMK (version).
7. Engagez-vous aussi souvent que possible . Si cela a tendance à être difficile (par exemple, quand il devrait y avoir trop de changements à faire pour implémenter des fonctionnalités et même compiler du code), des branches expérimentales doivent être utilisées.
8. Le tronc doit contenir le dernier développement . Par exemple, quand il y a un choix où développer une nouvelle version majeure ( Nxx ) de l'application, en tronc ou en branche, la décision doit toujours être prise en faveur du tronc . L'ancienne version doit être branchée dans la branche maintenance / support . Il suppose qu'il existe une distinction claire entre les versions majeures et leurs spécificités (architecture, compatibilité) émerge le plus tôt possible .
9. Politique stricte de «ne pas casser la construction» sur les branches de publication . En attendant, cela ne devrait pas nécessairement être strict pour le tronc tant qu'il peut avoir soit un développement expérimental, soit une base de code qui nécessite des problèmes de fusion pour être résolus.
10. Utilisez svn: externals . Il permettra de modulariser votre projet, d'établir une procédure transparente de gestion des versions, de diviser et de conquérir différentes fonctionnalités.
11. Utilisez le suivi des problèmes . Vous pourrez indiquer la référence du problème dans le message de validation.
12. Désactivez les messages de validation vides . Cela pourrait être fait en utilisant des hooks pré-commit.
13. Définissez les branches que vous souhaitez intégrer en permanence . Par exemple, je préfère utiliser l'intégration continue pour les branches de tronc , de maintenance et de version .
14. Établir une politique d'intégration continue pour différents types d'agences. Comme je l'ai souligné plus tôt, les règles les plus strictes "ne pas casser la construction" s'appliquent aux branches de publication , tandis que les branches de tronc et de maintenance peuvent parfois être cassées. Il y a également une différence entre la liste des inspections exécutées sur les branches de tronc / maintenance et de version .

Vous pouvez trouver un aperçu de mes meilleures pratiques de subversion sous forme de diagramme illustrant les grands principes de l'approche de gestion de la configuration logicielle que j'utilise.

Une chose que j'ai trouvée très utile est la propriété svn: external qui signifie que vous pouvez référencer des répertoires d'autres référentiels dans le vôtre. Cela donne de très bons moyens d'organiser votre code et vos données. Quelques exemples sont:

1. Si vous avez un référentiel séparé pour le code de différents modules / bibliothèques et référence dans ceux que vous utilisez. Cela signifie que vous pouvez avoir un méta-référentiel pour chaque exécutable. S'il s'agit d'un petit exécutable qui n'utilise que quelques modules, vous n'aurez pas besoin de récupérer l'arborescence entière. Cela a pour effet d'obtenir des numéros de révision SVN par module.
2. L'ajout de données binaires volumineuses telles que des versions compilées de bibliothèques au référentiel de code est généralement considéré comme une mauvaise habitude, mais cela peut être très pratique. Si vous ajoutez simplement toutes les versions de toutes les bibliothèques que vous utilisez à un référentiel différent, vous pouvez obtenir le meilleur de deux mondes. Vous référencez dans les versions des bibliothèques que vous utilisez dans votre référentiel de code. Lors de l'extraction de votre référentiel de code, vous obtiendrez également le code et les binaires. Cependant, les binaires sont stockés dans un grand référentiel que vous n'avez pas besoin de sauvegarder aussi rigoureusement que votre code source et le référentiel de code source reste petit et ne contient que du texte.

Utilisez l'intégration avec votre logiciel de suivi des bogues. Si vous utilisez Bugzilla , vous pouvez le configurer afin que si votre commentaire commence par "Bug XXXX", votre commentaire SVN est automatiquement ajouté en tant que commentaire au bogue donné, y compris un lien vers votre interface Web SVN vers cette révision.

Découvrez les outils et conventions de branchement et de fusion de SVN.

La meilleure façon de travailler avec d'autres membres de l'équipe est de diviser le travail en fonctionnalités / correctifs de développement complets, puis de travailler sur des changements individuels, chacun dans une branche. Ensuite, fusionnez les modifications dans la branche / le tronc principal une fois terminé / prêt / approuvé pour la fusion.

De cette façon, les individus peuvent travailler vers un objectif commun (soit sur la même branche, soit sur des branches séparées) sans entrer en collision avec d'autres changements.

Votre kilométrage peut varier, et cela peut être excessif pour seulement deux personnes ou plus.

Cela rend les choses beaucoup plus faciles si vous utilisez de bons outils qui s'intègrent bien avec SVN. Celles-ci permettent de voir facilement ce qui a été modifié, de valider tout ou partie de vos modifications et de mettre fréquemment à jour votre copie de travail vers la dernière version de SVN.

Je recommande Tortoise SVN (si vous utilisez Windows) et Visual SVN (si vous utilisez VS).

Vérifiez également si vous pouvez le configurer de manière à recevoir un e-mail ou une notification similaire à chaque fois qu'une modification est validée (comprenant généralement également le message de validation et une liste des fichiers modifiés). Des services comme CVSDude offrent cela. Je trouve utile de savoir à la fois qu'une mise à jour a été effectuée et d'avoir une idée de ce que contient cette mise à jour avant de mettre à jour ma copie de travail.

Outre les politiques de branchement et al. (où une taille ne convient certainement pas à tous), vous devriez avoir de bons commits:

• Le commit devrait concerner un seul morceau de travail si possible; un correctif de bogue, une nouvelle fonctionnalité - il devrait y avoir une certaine `` logique '' aux changements que vous avez commis
• Le commit doit avoir un commentaire descriptif qui vous aidera à le localiser en parcourant l'historique du référentiel. La plupart des gens suggèrent d'écrire une seule phrase au début qui décrit l'ensemble du commit et un compte plus détaillé ci-dessous
• Si possible, vous devez lier le commit à votre système de suivi des bogues si possible. Trac, Redmine et coll. vous permet de créer des liens entre les bogues et les commits et vice versa, ce qui est très pratique.

La règle d'or pour le contrôle de code source: enregistrez-vous tôt, enregistrez-vous souvent

Pour obtenir des conseils sur l'organisation de votre référentiel:

• Comment organisez-vous votre référentiel de contrôle de version?
• SVN Book Chapitre 5. Administration du référentiel
• Disposition du référentiel

Consultez votre équipe au sujet de leurs modifications, ou au moins examinez le diff très attentivement, avant de résoudre tout conflit de fusion. Demandez-leur de vérifier eux-mêmes le code fusionné pour s'assurer que leurs ajouts n'ont pas été perdus lors de la fusion.

Une chose que j'ai vue qui réduit les commits cassés est d'avoir de bons scripts de pré-commit. Par exemple, vous pouvez exécuter des tests unitaires avant que la modification ne soit validée. Cela ralentira un peu les engagements, mais vous gagnez du temps en évitant de marcher sur les pieds de quelqu'un et de devoir vous excuser. Bien sûr, cela devient beaucoup plus difficile à gérer lorsque vous avez une grande équipe de développement et des commits très fréquents.

Un des exemples d'intégration avec le suivi des bogues et l'application de la politique de commit pourrait être les scripts de hook svn pre / post-commit de Trac , qui peuvent refuser la validation si le message de commit ne fait référence à aucun ticket dans le bug-tracker et ajouter des commentaires à l'existant. tickets basés sur le contenu du message (c'est-à-dire que le message de validation peut contenir quelque chose comme "Corrections # 1, # 2 et # 8", où # 1, # 2, # 8 sont les numéros de tickets).

Meilleures pratiques pour utiliser SVN :

1. Lorsque vous êtes arrivé au bureau et que vous ouvrez votre projet Eclipse , la première étape à faire est de mettre à jour votre projet.

2. Après avoir pris la mise à jour, commencez votre travail. Lorsque vous avez terminé votre codage, vérifiez-le correctement, si votre application fonctionne correctement sans aucune exception. Une fois que vous êtes sûr que votre code fonctionne correctement, il est temps de valider le code.

Remarque: lors de la validation du code, ne vous engagez pas directement. Faites une synchronisation avec le serveur et vérifiez quels sont tous les besoins à valider. Remarque: ne validez pas tout le dossier une seule fois. Parce que vous avez peut-être apporté des modifications au fichier pour vos besoins ou que vous avez peut-être supprimé certains fichiers de votre système local. Mais les paramètres sont différents sur le serveur. Vérifiez donc les fichiers individuellement et validez le code.

3. Ne pas valider / mettre à jour les fichiers de conflit directement.

4. Quand faut-il remplacer et mettre à jour?

   Lorsque vous êtes à peu près sûr que vous n'avez besoin d'aucune de vos modifications locales et que vous souhaitez mettre à jour complètement la copie du serveur. Notez qu'une fois que vous effectuez le remplacement et la mise à jour, vous n'obtiendrez aucune de vos modifications locales.

   Remarque: ne conservez pas le projet sans mise à jour pendant plus d'une journée. Ne gardez pas non plus le code sans vous engager pendant plusieurs jours.

5. Communiquez qui travaillent tous dans le même composant et discutez des changements qu'ils ont apportés chaque jour.

6. Ne validez pas les propriétés et le fichier de configuration sauf s'il y a une raison. Parce que les paramètres seront différents sur un serveur et dans le cloud.

7. Ne validez pas les dossiers cibles dans SVN, seuls le code source et les dossiers de ressources doivent être conservés dans un référentiel SVN.

8. Lorsque vous avez perdu votre code, ne paniquez pas! Vous pouvez récupérer la copie précédente à partir de l'historique SVN.

9. Ne récupérez pas le projet à plusieurs endroits de votre disque. Vérifiez-le en un seul endroit et travaillez avec.

SVN en lui-même est un bon début et certaines des autres affiches ont offert d'excellentes suggestions sur les meilleures pratiques.

La seule chose que j'ajouterais est que vous devriez connecter SVN avec CruiseControl ou TeamCity pour conduire un processus d'intégration continue. Cela enverra des e-mails de build et informera tout le monde quand quelqu'un a cassé la build.

Ce sera très révélateur dès le début qui suit votre processus et qui ne le fait pas. Cela peut entraîner des frictions, mais votre équipe s'en sortira mieux à long terme.

• Commentaire précis pour chaque commit

• Ne cassez pas la construction (principale)!

• Validez dès qu'une unité logique change

• Évitez d'utiliser Subversion comme outil de sauvegarde

• Un peu de ramification / fusion possible

.

Plus de détails peuvent être trouvés dans les meilleures pratiques SVN .

Faire travailler DEV sur les branches

1. Engagements fréquents dans votre agence
2. Engagements discrets / modulaires dans votre agence ( voir ici )
3. Mettre à jour / fusionner souvent le tronc. Ne vous asseyez pas sur votre branche sans re-baser

Tronc communautaire

1. Devrait toujours construire / travailler
2. Un problème par commit ( voir à nouveau ici ) Surtout pour que vous ou d'autres puissiez revenir en arrière un à la fois
3. Ne confondez pas le refactoring / les changements d'espaces blancs avec des changements logiques. Vos coéquipiers auront du mal à extraire ce que vous avez réellement fait d'un commit

N'oubliez pas que plus vous effectuez vos commits de manière incrémentale, modulaire, discrète et succincte, plus il vous sera facile (ou probablement d'autres) de:

• Annuler progressivement les modifications
• Réalisez visuellement ce que vous avez réellement fait sans passer au crible des tonnes d'espaces blancs et des changements de nom variables.
• Les messages de validation ont plus d'importance lorsque le rapport entre le travail effectué et la longueur du message est inférieur.

Utilisez ceci pour le modèle de commentaires:

[tâche / histoire xxx] [mineur / majeur] [commentaire] [commentaire de suivi] [URL du bogue]