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

9

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?

version-control svn Wayne Molina
la source
5
Stratégie hors des sentiers battus: passez à git.
Rein Henrichs
Si c'était une option, je le ferais (ou Mercurial, puisque nous sommes une boutique Windows). Je pense que je ferais face à encore plus de résistance en essayant de passer à un tout nouveau système de contrôle de source qu'en essayant au moins de mettre en place un environnement approprié avec SVN.
Wayne Molina
2
Bien que je sois enthousiasmé par DVCS, Subversion est un bon outil. CVS ou une autre solution sans version de dossier serait pire.
Matthew Rodatus
2
@Wayne M - Vous trouverez peut-être que c'est l'inverse. Il pourrait être plus facile d'amener les gens à s'inscrire à une structure d'environnement plus sensible si cela leur donne tous les avantages d'utiliser un DVCS. En tant que transition, vous voudrez peut-être envisager d'amener Peopel à essayer un accès local de branchement / repo bon marché en utilisant gitsvn ou hgsubversion. Une fois qu'ils sont accrochés et habitués aux outils, il peut bien y avoir un désir à l'échelle du groupe de passer à un DVCS pour le ou les repo principaux.
Mark Booth,

Réponses:

5

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/
Matthew Rodatus
la source
1
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.
Matthew Rodatus
2
Si vous avez besoin de plusieurs versions unifiées, créez des répertoires sous tronc pour chacune. Mais, je ne nommerais pas un "dev" - c'est mieux accompli avec une branche. Par exemple, vous pouvez avoir deux organisations de développement principales - une qui fonctionne sur les pilotes de périphérique et une qui fonctionne sur le site Web de l'entreprise. Vous voudriez probablement deux versions unifiées distinctes.
Matthew Rodatus
1
  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.

Luke Graham
la source
Êtes-vous en train de dire que seul le code testé et prêt pour la production devrait être dans le coffre? Je pense que tout code engagé devrait générer et probablement passer des tests, et le code de tronc devrait bien sûr passer des tests. Mais il semble que le but de SVN soit de pouvoir suivre l'historique de développement, et c'est plus facile s'il n'est pas réparti sur plusieurs branches. Peut-être qu'il devrait y avoir une branche dans laquelle vous fusionnez le tronc lorsque le tronc est dans un état testé et prêt pour la production?
M. Jefferson
0

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.


la source
2
Je suis fortement en désaccord. Le référentiel fait plus que simplement stocker du code; il communique la structure organisationnelle et la relation entre les composants; il s'agit d'un canal de communication vital, quoique implicite. Si vous divisez chaque projet séparément, vous introduisez des barrières artificielles et inutiles à la communication.
William Payne