Структура управления исходным кодом Team Foundation Server

Я работаю над стандартизацией структуры управления версиями для нашего развертывания 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 в уровни соединительных линий/ветвей.

Ответы

Development/
   Trunk/
      Binaries/  -- Shared libraries
      Source/
      Test/
      Docs/      -- Documentation
TeamBuildTypes/  -- Build definitions