Я работаю над стандартизацией структуры управления исходным кодом для нашего развертывания Team Foundation Server на новый год. Я начал с использования документации по ветвлению Microsoft Team Foundation Server , доступной в 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}/
Общая логика заключается в том, что командный проект может содержать либо один логический проект (в котором не будет записи {Subproject}), либо несколько связанных проектов в форме продукта или набора инструментов. Три основных контейнера называются Development, Integration и Production.
Внутри ствола контейнера Development предусмотрены оба проекта, составляющих продукт, в папке Source, а соответствующие модульные тесты доступны в папке Tests. Большинство второстепенных разработок будет происходить в стволе, с разветвлением, доступным через одноуровневую папку Branches папки Trunk, которая действует как контейнер разветвления. Один или несколько файлов решения будут находиться в пределах Trunk, что позволяет ветвям на этом уровне регистрировать решение, исходные и модульные тесты.
Контейнер Integration, часто называемый «основным» в реализации не-TFS, используется исключительно для интеграции Changesets из 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 контейнера *1038* после принятия.
Мы считаем, что эта структура представляет собой справедливый баланс между надежностью и сложностью. Но есть несколько ноющих вопросов, которые я не могу вписать в модель. Это:
Team Build - Контейнеры Development и Integration изначально будут выполняться как ночные сборки, в конечном итоге перейдя к Continuous Integration (CI). Производственный контейнер будет построен вручную.
Где должны находиться определения сборки? Редактировать - на основе пары ответов папка TeamBuildTypes была перемещена в ствол и разветвлена в соответствующие контейнеры. Это, однако, приводит к новому вопросу (следует).
Имея папку TeamBuildTypes в соответствующих контейнерах, означает ли это, что все определения сборки будут воспроизводиться между соответствующими папками? Например, наличие определения сборки для качественных сборок разработки, а также тестируемых сборок и т. Д., Которые находятся во всех папках TeamBuildType во всей структуре.
Создание документации - Мы используем Sandcastle для создания документации. В частности, мы также используем Sandcastle Help File Builder для управления выводом. Это создает файл проекта в формате, определенном для SFHB. * 1068 *
Должна ли сгенерированная документация храниться в структуре контроля версий?
Должна ли быть создана документация для каждого контейнера, или она имеет значение только для подготовки производства и качества изготовления?
Чтобы сохранить быстрое локальное время сборки, должно ли создание документации принадлежать определению сборки?
Где должны храниться файлы, относящиеся к SHFB? Мое первоначальное предположение состоит в том, чтобы поместить его как одноранговый в папки Source и Tests. Я согласен с рекомендациями, что это будет одноранговый узел для Source и Tests. Диаграмма изменена, чтобы отразить это изменение.
Сторонние двоичные файлы
Должны ли двоичные файлы (элементы управления, библиотеки и т. Д.) Храниться в системе контроля версий?
Если так, то это должен быть собственный командный проект?
Общая документация - Не сгенерированная документация, такая как требования, проектная документация, планы испытаний и т. Д., Не будет отражаться в папке в структуре контроля версий. После некоторых исследований и обсуждений с моими разработчиками и коллегами использование встроенной папки «Документы» в Team Explorer дает больше преимуществ, поскольку она отражает структуру в портале Team Project, и некоторым (бизнес) пользователям не требуется дополнительная сложность изучения аспект управления исходным кодом TFS.
Я буду обновлять структуру по мере получения ответов на вопросы, чтобы получить более четкую картину. Я также приветствую любые другие комментарии, связанные с потенциальными изменениями. Если у меня возникнут другие вопросы, я обязательно внесу изменения в этот пост.
редактирует:
Разъяснение. Папки Source и Tests также находятся в контейнере Integration.
Мика и Джош подняли замечательные вопросы относительно сторонних двоичных файлов. Добавлен вопрос по вопросу.
Создание документации может быть медленным. Добавлен вопрос относительно того, должна ли документация принадлежать конкретному типу групповой сборки.
Добавлено разрешение, относящееся к не сгенерированной документации, такой как требования, проектная документация, планы испытаний и т. Д.
Добавлено определение, связанное с папкой TeamBuildTypes для определений сборки.
На основании различных отзывов переместил папку TeamBuildTypes на уровни магистрали / ветви.