Лучшая настройка для продвижения кода и разветвления функций в Subversion? - PullRequest
Новая
       14

Лучшая настройка для продвижения кода и разветвления функций в Subversion?

2 голосов
/ 20 февраля 2009

Мы команда из 4 человек и уже несколько лет не далеко от нашей зоны комфорта, но мы растем и хотели бы идти в ногу со временем. Мне было поручено найти лучший способ реализации Continuous Integration (автоматические сборки, ветвление для обслуживания кода и новые функции и т. Д.). Мы планируем перейти с SourceSafe 2005 на Subversion для управления нашей версией. Из того, что я прочитал, Subversion - намного лучший выбор для продвижения кода, веток и слияния ветвей. Мы, вероятно, будем использовать следующие продукты:

  • VisualSVN Server
  • TortoiseSVN (для интеграции с Windows Explorer)
  • VisualSVN (для интеграции с Visual Studio 2005)
  • SVNVB6 (для интеграции с Visual Basic 6)
  • FinalBuilder

Каков наилучший способ организации хранилища для продвижения кода и разветвления функций? Вот пример нашей текущей структуры SourceSafe:

  • корень
    • Проекты Visual Studio 2005
      • ProjectName
        • Файл решения, файлы проекта и файлы кода здесь
        • \ Bin
          • \ Release
            • Скомпилированные выпуски здесь
    • Visual Basic 6 проектов
      • ProjectName
        • Файлы проекта и файлы кодов здесь
        • Скомпилированные двоичные файлы (.dll, .exe, .ocx) здесь
    • Документация
      • Файлы документации здесь

Должны ли мы так структурироваться?

  • корень
    • веток (каждая ветвится от ствола)
      • Development.FeatureA
      • Development.FeatureB
      • Тест (Построен ночью с FinalBuilder ???)
      • Производство (Построен ночью с FinalBuilder ???)
      • Production.BugFixA (обратная интеграция в производственную ветку, тестовую ветвь и магистраль ???)
    • теги
      • Development.v1 (помечается после каждой успешной сборки)
      • Development.v2
      • Development.v3
      • Test.v1
      • Test.v2
      • Test.v3
      • Production.v1
      • Production.v2
      • Production.v3
    • багажник (Код разработки - Построен ночью с FinalBuilder)
      • Проекты Visual Studion 2005
        • ProjectName
          • Файл решения здесь
          • ProjectName
            • Файлы проекта и файлы кода здесь
      • Visual Basic 6 проектов
        • ProjectName
          • Файлы проекта и файлы кода здесь

Поскольку большая часть нашего программного обеспечения по-прежнему является COM (VB6) и должна быть зарегистрирована (используя regsvr32), должны ли двоичные файлы управляться версией? Как нам следует регистрировать / отменять регистрацию компонентов, когда нам нужно работать в разных ветвях (возможно, с разной совместимостью COM)?

Мы далеко от цели?

1 Ответ

2 голосов
/ 20 февраля 2009

Прежде всего, не используйте теги ветвей стволов верхнего уровня, используйте теги ветвей стволов для каждого проекта, как это: 

/Projects
  /CashCowProject
    /branches
    /tags
    /trunk
      /vs
      /doc

Это означает, что инструменты отслеживания могут просматривать http://svn/Projects/CashCowProject и видеть ВСЕ действия в этом проекте, а не получать какие-либо действия в любом другом проекте. Также он заставляет вас контролировать ссылки между проектами, а это означает, что ваши проекты верхнего уровня не изменятся без записи в транке.

Когда проекты ссылаются друг на друга, используйте svn: externals, чтобы получить тег из нужного вам проекта библиотеки. Используйте ветки поставщиков, как описано в книге о красных компонентах, для работы со сторонними библиотеками, даже двоичными.

Хранение двоичных файлов библиотеки в SVN в порядке. Возможно, для этого стоит рассмотреть отдельный репозиторий, хотя мы этого не делаем.

Для продвижения кода сохраняйте стабильную ветвь для конкретной версии и объединяйте ее только из транка в эту ветвь, а затем добавляйте тег из этой ветки. Это даст вам отчет о том, что находится в каждом выпуске.

Вы можете оставить там двоичные файлы COM, если не собираетесь извлекать исходный код и собирать его. Вы можете написать скрипт после обновления для черепахи, который будет регистрировать любые найденные COM-объекты.

...