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

Question

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

Просто чтобы начать движение, вот обзор того, что я видел.

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

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

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

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

Answer 1

Мы практикуем высококомпонентную разработку с использованием Java, у нас есть около 250 модулей в транке, которые имеют независимые жизненные циклы. Зависимости управляются через Maven (это лучшая практика), каждая активно развивающаяся итерация (раз в две недели) помечается новой версией. Трехзначные номера версий со строгой семантикой (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 может помочь здесь, так как он диктует структуру. Многие структуры хороши, если вы придерживаетесь их.

Answer 2

Пример для SVN:

багажник /

филиал /

Теги /

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

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

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

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

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

Answer 3

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

• Ствол
  • 1007 * конфигурация *
  • документы
  • SQL
    • начальная
    • Обновления
  • ЦСИ
    • приложение
    • тест
  • ThirdParty
    • Lib
    • инструменты
• метка
• филиалы

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

Мой файл решения помещается прямо в директорию транка вместе с моими файлами сборки.

Answer 4

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

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

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

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

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

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

Существует также мой ответ на вопрос о «Несколько репозиториев SVN против репозитория одной компании». Это может быть полезно, если вы ответите на этот аспект структурирования репозитория в своем вопросе.

Answer 5

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

• Магистральные

  • Планирование и отслеживание
  • Req
  • Дизайн
  • Строительство
    • Bin
    • База данных
    • Lib
    • Источник

• Deploy

• QA
• MA

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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

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

Answer 9

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

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

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

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