Я работаю над стандартизацией структуры управления версиями для нашего развертывания Team Foundation Server в течение нового года. Я начал с использования документации Microsoft Team Foundation Server Branching Guidance на CodePlex.
Я надеялся получить некоторые отзывы и ответы на некоторые из конкретных вопросов, которые у меня есть о предлагаемой структуре. Когда дело доходит до структурирования источника управления в TFS, я узнал, что существует так много "стандартов", чтобы выбрать из того, что на самом деле нет стандарта.
Во-первых, я опишу и опишу решения и использование.
$/
{Team Project}/
{Subproject}/
Development/
Trunk/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Branches/
{Branch Name}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Integration/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Production/
Releases/
{Release Version}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Branches/
{Branch Name}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Общая логика заключается в том, что Team Project может содержать либо один логический проект (где не было бы записи {Subproject}
), либо несколько связанных проектов в виде продукта или набора инструментов. Три основных контейнера называются Development
, Integration
и Production
.
В контейнере контейнера Development
существуют положения для обоих проектов, которые составляют продукт в папке Source
, с соответствующими модульными тестами, доступными в папке Tests
. Большая часть незначительного развития будет происходить в туловище, причем ветвление доступно через папку Trunk
sibling Branches
, которая действует как контейнер разветвления. Один или несколько файлов решений будут жить в пределах Trunk
, позволяя ветвям на этом уровне отображать решения, исходные и модульные тесты.
Контейнер Integration
, который часто называется "основным" в реализации, отличном от TFS, используется исключительно для интеграции наборов изменений из Development
для создания стабильной и тестируемой сборки. Он первоначально создается как ветвь из контейнера Development
, как только тестируемый продукт будет достигнут. Сборки из этого контейнера будут использоваться для нашей тестовой среды и среды тестирования нагрузки. Мы решили включить тестирование нагрузки с помощью тестируемых сборок, чтобы мы могли следить за изменениями в производительности, будучи в состоянии быстро изолировать группы изменений, которые могли внести вклад в любые нарушения.
Production
используется для производства готовых и производственных качеств. Он первоначально создается как ветвь из контейнера Integration
, как только стабильная сборка была рекомендована для выпуска. Внутри папки Releases
выполняется структура "ветвь по версии", обеспечивающая моментальный снимок и изоляцию в одном месте. (Например, когда Release 1.1
готов к предварительной сборке, стабильный контейнер Integration
разветвляется в новую папку Release 1.1
в структуре Production/Releases
. Последующие RC файлы и RTW/RTM файлы продвигаются в эту папку, также). Также существует ветвящаяся структура, как показано в контейнере Branches
. Это позволяет "исправления", как правило, маркер ревизии (Major.Minor.Revision). Филиал создается из текущей версии и объединяется обратно в новый маркер версии - например, Release 1.1.1
. После принятия изменений блок изменений будет интегрирован обратно в контейнер Development
Trunk
.
Мы считаем, что эта структура является справедливым балансом между надежностью и сложностью. Но есть несколько вопиющих вопросов, которые я не могу логически вписаться в модель. Это:
Team Build. Контейнеры Development
и Integration
изначально начинаются как ночные сборки, в конечном итоге переходя к Continuous Integration (CI). Контейнер производства будет создан вручную.
-
Где должны существовать определения сборки?Изменить. Основываясь на нескольких ответах, папка TeamBuildTypes была перемещена в туловище и разветвлена в соответствующие контейнеры. Это, однако, приводит к новому вопросу (следует). -
Имея папку TeamBuildTypes в соответствующих контейнерах, означает ли это, что все определения сборки будут воспроизводиться между соответствующими папками? Например, определение сборки для построения качества разработки, а также тестируемые сборки и т.д., Все из которых находятся во всех папках TeamBuildType по всей структуре.
Генерация документации. Мы используем Sandcastle для создания документации. В частности, мы также используем Sandbule Help File Builder для управления выходом. Это создает файл проекта в формате, специфичном для SFHB.
-
Должна ли сгенерированная документация храниться в структуре управления источником?
-
Должна ли создаваться документация для каждого контейнера или она имеет только ценность для сборки для производства и производства?
-
Чтобы сохранить быстрые локальные времена сборки, должно ли создание документации быть владельцем определения сборки?
-
Где должны быть файлы, специфичные для SHFB? Моя первоначальная информация заключается в том, чтобы поместить ее как одноранговый узел в папкиЯ согласен с рекомендациями, что это будет равнымSource
иTests
.Source
иTests
. Диаграмма изменилась, чтобы отразить это изменение.
Сторонние бинарные материалы
-
Должны ли храниться двоичные файлы (элементы управления, библиотеки и т.д.) в источнике управления?
-
Если это так, должен ли он быть собственным Team Project?
Общая документация. Не созданная документация, такая как требования, проектные документы, планы тестирования и т.д., не будет отображаться в папке в структуре управления источником. После некоторых исследований и обсуждения с моими разработчиками и сверстниками использование встроенной папки "Документы" в Team Explorer обеспечивает большую выгоду, поскольку она отражает структуру в Team Project Portal, а некоторым (бизнес-пользователям) не требуется дополнительная сложность обучения аспект контроля источника TFS.
Я обновляю структуру, поскольку получаю ответы на вопросы, чтобы обеспечить более четкое изображение. Я также приветствую любые другие комментарии, связанные с потенциальными изменениями. Если у меня возникнут другие вопросы, я обязательно изменю этот пост.
редактирует:
-
Разъяснение.
Source
иTests
сохраняются в контейнереIntegration
. -
Оба Мика и Джош подняли большие точки в отношении сторонних двоичных файлов. Вопрос добавлен в отношении проблемы.
-
Генерация документации может быть медленной. Добавлен вопрос о том, должно ли создание документации принадлежать определенному типу сборки Team.
-
Добавлено разрешение, связанное с не созданной документацией, например требованиями, проектной документацией, планами тестирования и т.д.
-
Добавлено решение, связанное с папкой TeamBuildTypes для исправлений сборки.
-
Основываясь на различных отзывах, переместили папку TeamBuildTypes в уровни соединительных линий/ветвей.