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

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

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

Пример для SVN:

trunk/

branch/

tags/

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

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

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

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

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

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

• багажник
  • конфиг
  • доктора
  • sql
    • первоначальный
    • новинки
  • src
    • апп
    • тест
  • третья сторона
    • либ
    • инструменты
• метить
• ветви

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

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

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

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

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

• Багажник

  • Planning&Tracking
  • Запрос
  • Дизайн
  • Строительство
    • Мусорное ведро
    • База данных
    • Библиотека
    • Источник

• Развертывать

• QA
• MA

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

/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 означает стабильный

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

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

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

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

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

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

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

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

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

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

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

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

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

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