я работаю над стандартизацией структуры управления версиями для развертывания Team Foundation Server на Новый год. Я начал с использования Майкрософт Сервера Team Ветвления Руководством документация доступна на сайте 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 папка с соответствующими модульными тестами, доступными в . Большая часть незначительного развития произойдет в стволе, с ветвлением, доступным через Trunk папки-двойники Branches папка, которая действует как ветвящийся контейнер. Один или несколько файлов решений будут жить в Trunk, позволяющ для ветвей на этом уровне захватить решение, источник, и блок тесты.

на Integration контейнер, часто называемый "main" в реализации без TFS, используется исключительно для интеграции наборов изменений из Development для создания стабильной и тестируемой сборки. Первоначально он создается как ветвь из Development контейнер как только тестируемый продукт был достигнут. Сборки из этого контейнера будут использоваться для нашей среды тестирования и среды нагрузочного тестирования. Мы решили включить нагрузочное тестирование с тестируемыми сборками, чтобы мы могли отслеживать изменения в производительность, возможность быстрой изоляции изменений, которые, возможно, способствовали какие-либо нарушения.

Production использовано для того чтобы произвести строения пре-продукции и качества продукции. Первоначально он создается как ветвь из Integration контейнер после того, как стабильная сборка была рекомендована для выпуска. В Releases папка, структура" ветвь выпуском " следует, обеспечивая snapshotting и изоляцию в одном месте. (Например, когда Release 1.1 готов к пре - продукция строит, конюшня Integration контейнер разветвляется на новый на Production/Releases структура. Последующие RCs и RTWs / RTMs также продвигаются в эту папку.) Ветвящаяся структура также присутствует, как видно из Branches контейнер. Это позволяет использовать "исправления", обычно маркер ревизии (Major.Незначительный.Пересмотр.) Ветвь создается из текущего выпуска и объединяется обратно в новый маркер редакции-как Release 1.1.1. Набор изменений будет реверсивно интегрирован к Development контейнера Trunk С момента его принятия.

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

Team Build - в Development и Integration контейнеры первоначально будут начинаться как ночные сборки, в конечном итоге переходя к непрерывной интеграции (CI). Контейнер продукции будет вручную построенный.

• где должны жить определения сборки? Edit-на основе нескольких ответов папка TeamBuildTypes была перемещена в магистраль и разветвлена на соответствующие контейнеры. Это, однако, приводит к новому вопросу (следует).

• имея папку TeamBuildTypes в соответствующих контейнерах, означает ли это, что все определения сборки будут воспроизводиться между соответствующие папки? Например, наличие определения сборки для сборки качества разработки, а также тестируемых сборок и т. д. все живут во всех папках TeamBuildType по всей структуре.

Документация - мы используем Sandcastle для создания документации. В частности, мы также используем Sandcastle Help File Builder для управления производством. Это создает файл проекта в формате, специфичном для SFHB.

• должна ли сгенерированная документация храниться в структуре управления версиями?

• должна ли документация создаваться для каждого контейнера или она имеет значение только для сборки предварительного производства и качества производства?

• чтобы сохранить быстрое локальное время сборки, должно ли создание документации принадлежать определению сборки?

• где должен SHFB-специфический файлы живут? Мой первоначальный намек-поставить его как Пэра Source и Tests папки. я согласен с recommondations, что это будет равный Source и Tests. Схема изменена, чтобы отразить это изменение.

Сторонние Двоичные Файлы

• должны ли двоичные файлы (элементы управления, библиотеки и т. д.) храниться в системе управления версиями?

• если это так, Должно ли это быть это собственный командный проект?

Общие Документы - non-произведенная документация, как требования, проектные документы, планы испытания, etc. не будут отражены в папке в структуре управления версиями. После некоторых исследований и обсуждений с моими разработчиками и коллегами использование встроенной папки "документы" в Team Explorer дает больше преимуществ, поскольку она отражает структуру портала командного проекта, а некоторые (бизнес-пользователи не нужна дополнительная сложность изучения аспекта управления версиями TFS.

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

изменения:

• уточнение. Source и Tests папки живут под Integration контейнер, а также.

• и Мика, и Джош подняли отличные моменты относительно сторонних двоичных файлов. Вопрос добавлен относительно вопроса.

• генерация документации может быть медленным. Добавлен вопрос о том, Должно ли создание документации принадлежать определенному типу командной сборки.

• добавлено разрешение, связанное с не сгенерированным документы, такие как требования, проектной документации, планов тестирования и т. д.

• добавлено разрешение, связанное с папкой TeamBuildTypes для определений сборки.

• основываясь на различных отзывах, переместил папку TeamBuildTypes на уровни магистрали / ветви.