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

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

Мы переходим модули/блоки, когда мы должны сделать исправление ошибки или улучшение для выпущенной версии, и мы не можем обеспечить ГЛАВНУЮ версию. Отмечание всех версий делает это легким сделать, но ответвления все еще подвергаются значительным административным издержкам (конкретно сохраняющий ответвления в синхронизации с определенным ГЛАВНЫМ changesets), которые частично вызываются нашими инструментами, Подверсия является субоптимальной для управления ответвлениями.

Мы находим, что довольно плоское и прежде всего предсказуемый древовидная структура в репозитории крайне важно. Это позволило нам создавать инструменты выпуска, которые устраняют большую боль и опасность от ручного процесса выпуска (обновленная информация о версии, компиляции проекта, модульные тесты пробегают, тег сделан, никакие зависимости от СНИМКА, и т.д.). Постарайтесь не помещать слишком много классификации или другую логику в Вашей древовидной структуре.

Мы примерно делаем что-то как следующее:

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/
      ...

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

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

Пример для SVN:

соединительная линия /

ответвление /

теги /

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

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

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

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

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

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

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

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

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

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

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

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

• Соединительная линия

  • Planning& Отслеживание
  • Конструкция Дизайна
  • <ул.> <литий> мусорное ведро Req
  <литий> База данных <литий> Lib <литий> Источник

• Развертывается

• QA
• MA

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

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

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

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

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

Управление исходным кодом для исходного кода, не двоичных файлов. Сохраните любые сторонние блоки/банки в отдельном репозитории. Если Вы работаете в мире Java, пробуют что-то как Знаток или Ivy. Поскольку .NET предполагает, что простой общий диск может работать хорошо, пока у Вас есть достойные политики вокруг, как он структурирован и обновлен.

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

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

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

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