Venir avec une stratégie de contrôle de version pour SVN

Hors du temps, je vais essayer de trouver une stratégie de contrôle de version pour mon entreprise; nous utilisons actuellement SVN mais il n'y a pas de structure - nous n'avons essentiellement qu'un tronc et nous nous engageons uniquement à cela. Récemment, le responsable du développement a démarré un deuxième référentiel qui agit comme notre "tag", mais il doit être fusionné manuellement avec le "tronc" car il ne fait pas partie du même référentiel mais est totalement séparé. En effet, il n'y a qu'un seul dossier, appelé "Dev" (il y a en fait différents dossiers "Dev" à différentes dates mais juste "Dev" est le principal) et en dessous c'est tout le reste; tous les autres projets. Ce n'est pas organisé par projet du tout, il n'a aucun concept de branches / tag / tronc ou quoi que ce soit. La personne qui l'a installé initialement (disparu depuis longtemps, bien sûr) semblait ne pas savoir du tout comment configurer SVN, et depuis lors, personne n'a pris la peine d'apprendre à faire les choses correctement de peur de casser quelque chose. Nous n'utilisons aucun type de CI (ou test automatisé, malheureusement).

Premièrement, devrions-nous le séparer par projet? Par exemple, nous avons: deux sites Web ASP.NET (pas des applications Web, des sites Web), un service Web, un dossier de déploiement pour tous les scripts de table et les procédures stockées, deux clients de ligne de commande pour les projets externes qui sont appelés par le Sites Web et dossier partagé contenant des objets métier communs et similaires. Est-ce que chacun d'entre eux doit être son propre projet avec une configuration branches / tag / trunk, ou devrait-il être comme ceci:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

et ont toutes les branches et tout ont une copie de l'ensemble du dossier Dev? Cette approche pourrait être plus facile à avaler car nous avons souvent des situations où nous devons apporter des modifications dans la bibliothèque de code partagée et au moins un (généralement les deux) des sites Web.

Deuxièmement, nous publions régulièrement ("push" dans notre langage) sur notre serveur de développement et notre serveur en direct. D'après ce que j'ai lu, la meilleure façon de gérer cela serait que tout le développement va dans le tronc /, les branches sont "temporaires" et utilisées pour ajouter une nouvelle fonctionnalité qui pourrait affecter le tronc, et les balises sont pour les versions? Donc, nous poussons chaque mois, disons, et je travaille sur un tout nouveau module. Je branchais le tronc, et j'utilisais cette branche pour mon code, l'écrivant et le testant, etc. Une fois le module terminé, je le fusionnerais à nouveau dans le tronc (et je supprimerais peut-être la branche), et lorsque nous serions prêts à déployer, nous le marquerions («May2011», disons). Si nous avons un correctif de bogue après sa mise en ligne, il serait corrigé dans la balise May2011 et fusionné dans trunk (donc trunk obtient également le correctif), puis May2011 serait repoussé avec le correctif? Est-ce l'intention de marquer?

Si vous voulez un processus de construction unifié, assurez-vous de placer les branches / balises / tronc à la racine, comme ceci:

branches/
tags/
trunk/
  dev/
    ...

Si vous n'avez pas besoin d'un processus de construction unifié, vous pouvez mettre des branches / balises / troncs dans chaque projet si vous le souhaitez. Cependant, il peut être difficile de migrer vers une version unifiée après les avoir placés dans chaque projet. Une version unifiée présente des avantages, comme l'élimination de la nécessité de publier des composants partagés entre les projets - ils font tous partie de la version.

Personnellement, j'aime un processus de construction unifié. De plus, je ne pense pas que vous devriez avoir un projet "dev". Vous devez avoir des projets directement sous trunk, puis branchez trunk dans une branche dev. Utilisez des balises pour les versions. Par exemple, je le ferais comme ceci:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

1. En ce qui concerne la structure du code dans svn, c'est vraiment un choix personnel.

Je dirais que si les projets sont liés ou partagent du code, ils veulent un tronc commun. S'ils sont indépendants, ils veulent des troncs séparés ou même des référentiels séparés. Si vous avez besoin de fournir à un tiers une copie de l'historique svn d'un projet, il est beaucoup plus facile s'il se trouve dans un référentiel séparé.

Donc, dans votre cas, il semble que la disposition que vous avez esquissée ci-dessus soit raisonnable, car vous avez du code partagé et vous souhaitez que les branches / balises incluent ce code partagé.

1. Votre description des balises et des branches utilise des sons éminemment sensés et c'est ainsi que je m'attendrais à ce que svn soit utilisé. C'est en effet l'intention de marquer comme je le comprends. BTW dans les balises svn et les branches est en fait la même chose, mais la terminologie est appliquée comme vous l'avez appliquée.

Personnellement, j'ajouterais également la mise en garde que tout ce qui est engagé dans le tronc doit être construit, doit être atomique et ne doit pas casser les tests unitaires. Les succursales sont pour les travaux en cours inachevés. Je m'attendrais à ce que le tronc soit un candidat potentiel à une version à tout moment.

Ce qui suit est le meilleur moyen de disposer un référentiel Subversion

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

De cette façon, vous pouvez vérifier les projets individuels par eux-mêmes.

Si vous voulez vérifier les 3 projets et faire une construction unifiée avec un script / système de construction monolithique, alors étudiez l'utilisation d'un module maître avec svn: externals mappant tous les autres projets dans le maître trunk .

C'est plus compliqué à première vue, mais c'est la façon la plus maintenable et idiomatique de résoudre ce problème avec Subversion.