Структура проектов в управлении версиями

Я знаю, что существует как минимум 10 различных способов структурирования проекта в управлении версиями. Мне любопытно, какие методы используются и какие из них работают на вас. Я работал с SVN, TFS и в настоящее время/к сожалению VSS. Я видел, что контроль версий реализован очень плохо и просто ОК, но никогда не замечательный.

Просто, чтобы заставить мяч прокатиться, вот обзор вещей, которые я видел.

Этот пример основан на SVN, но применяется к большинству VCS (не столько к распределенному контролю версий).

отделить отдельные проекты, которые являются частью сайта /Отдел/Web/Projectname/VB/SRC/[ствол | ветки | теги]
Разделите весь сайт, в том случае, если я видел, весь сайт, кроме основных компонентов, был разветвлен. /Деление/[ствол | ветвь | теги]/Web/Projectname/VB/SRC/
Использовать основную строку по умолчанию, только при необходимости, для ветвления огромных изменений.

Ответ 1

Мы практикуем высококомпетентную разработку с использованием Java, у нас около 250 модулей в багажнике, которые имеют независимые жизненные циклы. Зависимости управляются через Maven (это лучшая практика прямо там), каждая итерационная (раз в две недели) активно разрабатываемые модули получают помеченные новой версией. 3-значные номера версий со строгой семантикой (major.minor.build - основные изменения означают обратную сторону несовместимые, незначительные изменения означают обратную совместимость и изменения числа номеров, означающие совместимость в обратном и вперёд). Наш конечный программный продукт представляет собой сборку, в которую входят десятки отдельных модулей, опять же как зависимости от Maven.

Мы объединяем модули/сборки, когда нам нужно исправить ошибку или улучшить выпущенную версию, и мы не можем доставить версию HEAD. Маркировка всех версий делает это легко, но ветки по-прежнему несут значительные административные издержки (в частности, синхронизация ветвей с некоторыми наборами изменений HEAD), которые частично вызваны нашими инструментами, Subversion не оптимальна для управления ветвями.

Мы обнаруживаем, что достаточно плоская и, прежде всего, предсказуемая древовидная структура в репозитории имеет решающее значение. Это позволило нам создавать инструменты выпуска, которые отвлекают большую часть боли и опасности от процесса ручного выпуска (обновленные заметки о выпуске, компиляции проектов, проецирование модулей, создание тегов, отсутствие зависимостей SNAPSHOT и т.д.). Избегайте слишком много категоризации или другой логики в вашей древовидной структуре.

Мы грубо делаем что-то вроде следующего:

svnrepo/
  trunk/
    modules/
      m1/ --> will result in jar file
      m2/
      ...
    assemblies/
      a1/
      ...
  tags/
    modules/
      m1/
        1.0.0/
        1.0.1/
        1.1.0/
       m2/
      ...
    assemblies/
      a1/
        iteration-55/
        ...
  branches/
    m1/
      1.0/
      ...

Для внешних зависимостей я не могу переоценить что-то вроде Maven: управляйте своими зависимостями как ссылки на версированные, уникально идентифицированные бинарные артефакты в репозитории.

Для внутреннего модуля/структуры проекта: придерживайтесь стандарта. Однородность является ключевым фактором. Опять же, Maven может помочь здесь, поскольку он диктует структуру. Многие структуры прекрасны, если вы придерживаетесь их.

Ответ 2

Пример для SVN:

Ствол/

ветки/

/теги

Строка должна храниться в точке, где вы всегда можете выталкивать ее. Не должно быть огромных жужжащих ошибок, о которых вы знаете (конечно, в конце концов, но это то, к чему вы должны стремиться).

Каждый раз, когда вам нужно создать новую функцию, измените дизайн, независимо от того, какая ветка. Отметьте эту ветку в начале. Затем, когда вы закончите с тегом ветки в конце. Это помогает слиянием обратно в багажник.

Каждый раз, когда вам нужно нажать релиз, тег. Таким образом, если что-то идет ужасно неправильно, вы можете откат к предыдущему выпуску.

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

Изменить: Для сторонних вещей это зависит. Если я могу избежать этого, у меня его нет под контролем источника. Я храню его в директории внешнего источника и включаю его оттуда. Для таких вещей, как jquery, я оставляю это под контролем источника. Причина в том, что он упрощает мой script для нажатия. Я могу просто заставить его экспортировать svn и rsync.

Ответ 3

Для моих проектов я всегда использую эту структуру.

Ствол
конфигурации

документы

SQL
начальная

обновления

ЦСИ
Приложение

тест

ThirdParty
Lib

Инструменты

теги

ветки

config - используется для хранения шаблонов конфигурации приложения. Во время процесса сборки я беру эти шаблоны и заменяю метки токенов фактическими значениями в зависимости от того, какую конфигурацию я создаю.
docs - здесь размещается любая документация по приложениям.
sql - я разбиваю свои sql-скрипты на два каталога. Один для начальной настройки базы данных, когда вы начинаете новую, и другое место для моих сценариев обновления, которые запускаются на основе номера версии базы данных.
src - исходные файлы приложения. Здесь я разбиваю исходные файлы на основе приложений и тестов.
thirdparty - Здесь я помещаю свои сторонние библиотеки, которые я ссылаюсь внутри своего приложения и недоступен в GAC. Я разделил их на основе lib и инструментов. В каталоге lib хранятся библиотеки, которые необходимо включить в приложение. В каталоге tools хранятся библиотеки, к которым ссылается мое приложение, но они используются только для запуска модульных тестов и компиляции приложения.

Мой файл решения размещается прямо под каталогом соединительных линий вместе с моими файлами сборки.

Ответ 4

Я могу оценить логику не поместить двоичные файлы в репозиторий, но я думаю, что есть огромное преимущество. Если вы хотите получить конкретную ревизию из прошлого (обычно это старый тег), мне нравится иметь все, что мне нужно, из проверки svn. Конечно, это не включает Visual Studio или .NET framework, но с правильной версией nant, nunit, log4net и т.д. Очень легко перейти от проверки к сборке. Таким образом, начало работы так же просто, как "svn co project", за которым следует "nant build".

Одна вещь, которую мы делаем, - это вставить двоичные файлы ThirdParty в отдельное дерево и использовать svn: external, чтобы принести ему нужную нам версию. Чтобы сделать жизнь легкой, у нас будет папка для каждой используемой версии. Например, мы могли бы принести папку ThirdParty/Castle/v1.0.3 в текущий проект. Таким образом, все, что нужно для сборки/тестирования продукта, находится внутри или ниже корня проекта. Компромисс в области дискового пространства стоит того, что нам нужно.

Ответ 5

Поскольку у нас есть все артефакты и конструкция в одном и том же дереве, мы имеем что-то вроде:

Магистральные
- Планирование & Tracking
- Req
- Дизайн
- Строительство
  - Bin
  - База данных
  - Lib
  - Источник
Deploy
ОК
MA

Ответ 6

Я предпочитаю мелкозернистые, очень организованные, автономные структурированные репозитории. Существует диаграмма иллюстрирующая общий (идеальный) подход процесса обслуживания репозитория. Например, моя первоначальная структура репозитория (каждый репозиторий проекта должна иметь):

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

PA означает pre-alpha A означает alpha B означает betastrong > AR означает альфа-релиз BR означает бета-релиз RC означает кандидат на выпуск ST означает стабильный

Существуют различия между сборками и выпусками.

Теги в папке builds имеют номер версии, соответствующий шаблону N.x.K, где N и K являются целыми числами. Примеры: 1.x.0, 5.x.1, 10.x.33
Теги в папке выпуска содержат номер версии, соответствующий шаблону N.M.K, где N, M и K являются целыми числами. Примеры: 1.0.0, 5.3.1, 10.22.33.

Недавно я разработал тренинг, посвященный Software Configuration Management, в котором описываю подход к нумерации версий и почему именно эта структура репозитория является лучшей. Ниже представлены слайды презентаций .

Существует также ответ fooobar.com/questions/107343/... о 'Множественных хранилищах SVN и репозиториях одной компании ". Это может быть полезно, если вы рассматриваете этот аспект структурирования репозитория в своем вопросе.

Ответ 7

Я думаю, что политики и процедуры SCM, которые команда принимает, будут сильно зависеть от процесса разработки, который они используют. Если у вас есть команда из 50 человек с несколькими людьми, которые работают над крупными изменениями одновременно, и выпуски происходят только каждые 6 месяцев, для каждого имеет смысл иметь собственную ветку, где он может работать изолированно и только сменять изменения от другие люди, когда он хочет их. С другой стороны, если вы - команда из 5 человек, которые сидят в одной комнате, имеет смысл разветвляться гораздо реже.

Предполагая, что вы работаете в небольшой команде, где общение и сотрудничество хороши, а выпуски часто бывают, очень мало иметь в виду отделение IMO. В одном проекте мы просто перевернули номер версии SVN в номер версии продукта для всех наших выпусков, и мы даже не отметили его. В редком случае, когда в prod произошла критическая ошибка, мы просто отделились бы от версии, выпущенной. Но большую часть времени мы просто исправляли ошибку в ветке и освобождались от сундука в конце недели по расписанию. Если ваши выпуски достаточно часты, вы почти никогда не столкнетесь с ошибкой, которая не может дождаться следующей официальной версии.

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

Я также упомянул, что все, что я написал, исходит из ИТ-инфраструктуры предприятия, где есть только один производственный экземпляр данной базы кода. Если бы я работал над продуктом, который был развернут на 100 различных клиентских сайтах, методы разветвления и тегов были бы немного более напряженными, чтобы управлять всеми независимыми циклами обновления во всех экземплярах.

Ответ 8

Как насчет внешних зависимостей, таких как AJAXTookit или какое-то другое стороннее расширение, используемое в нескольких проектах?

Исходный код предназначен для исходного кода, а не для двоичных файлов. Храните любые сторонние сборки/банки в отдельном хранилище. Если вы работаете в мире Java, попробуйте что-то вроде Maven или Ivy. Для проектов .Net простой общий диск может работать хорошо, если у вас есть приличные политики в отношении того, как он структурирован и обновлен.

Ответ 9

Мы перешли из плохого мира VSS с одним гигантским хранилищем (более 4G), прежде чем переключиться на SVN. Я действительно боролся с тем, как создать новый репозиторий для нашей компании. Наша компания - очень "старая" школа. Мне сложно меняться. Я один из молодых разработчиков, а мне 45! Я являюсь частью команды по корпоративному развитию, которая работает над программами для ряда отделов в нашей компании. В любом случае, я создал наши каталоги, подобные этому

+ devroot
    +--Dept1
        +--Dept1Proj1
        +--Dept2Proj2
    +--Dept2
        +--Dept2Proj1
    +--Tools
        +--Purchase3rdPartyTools
        +--NLog
        +--CustomBuiltLibrary

Я хотел включить способность к ветке, но, честно говоря, это слишком много на данный момент. Пара вещей, которые мы по-прежнему пытаемся использовать с этой схемой.

Трудно решить проблемы с производительностью, если вы работаете над крупным обновлением продукта (т.е. потому что мы не занимаемся ветвлением)
Трудно управлять концепцией продвижения от "Dev" к "Prod". (Даже не спрашивайте о продвижении в QA).