none
Методология расщепления проектов в TFS RRS feed

  • Общие обсуждения

  • (Если это уже где-то обсуждалось – дайте ссылку, плиз)

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

    Проект называется "Базовый функционал" или "Startup".

    Затем по мере развития и по окончании этого проекта данная команда будет разделена на 2 команды, которые будут заниматься своими проектами – они будут развивать все тот же код, но каждая команда будет в рамках своих проектов развивать отдельные функции системы. Набор этих функций заранее не известен, пакет новых функций, которые предстоит реализовать в рамках нового проекта (длительностью в несколько месяцев, полгода или год), будет формироваться перед стартом соответствующего проекта. В будущем команд может быть не 2, а 3 или 4. Соответственно по мере надобности нанимаем новых разработчиков для формирования команд.

    Вопрос как с позиции Team Project организовать такое расщепление команд/проектов?

    Я вижу 2 варианта.

     

    1. Иерархия итераций в одном командном проекте

    В этом варианте используется всего один командный проект (Team Project). Итерации в командном проекте 2-хуровневые. 1-й уровень – это отдельные проекты команд, 2-й уровень – собственно итерации. Группа итераций 1-го уровня, представляя собой проект, закрепляется за отдельной командой. Закрепление происходит в головах разработчиков, т.к. в TFS средств для такого закрепления нет – хотя может быть возможно раздавать права на отдельные итерации (группы итераций) отдельным группам/пользователям? По мере необходимости в командном проекте (Team Project) пользуемся ветвлением для отдельных проектов команд (итерации 1-го уровня).

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

    Кроме того, многие отчеты, охватывающие командный проект, в целом могут оказаться бессмысленными, поскольку командный проект как таковой теряет смысл – имеют смысл лишь проекты (группы итераций 1-го уровня).

    Опять же не возникнет ли методологических проблем при заведении ворк-айтемов.

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

    Однако, достоинство этого подхода – простота.

     

    2. Много командных проектов

    В этом варианте используется по одному командному проекту для каждого отдельного проекта команд. Кроме того, имеется один "холостой" командный проект (без ворк-айтемов, но с кодом), называемый допустим Integration, где будет присутствовать код в 3-х ветвях: Main, Staging и Production.

    Командные проекты соответствующие реальным проектам команд, возможно, не будут иметь кода совсем, а будут иметь только ворк-айтемы. В этом случае чекины будут производиться в $/Integration/Main. На момент создания отдельного командного проекта в ветке $/Integration/Main делаем метку для возможного ответвления в будущем в этот отдельный командный проект, если в этом возникнет необходимость. Такая схема доступна только в том случае, если отдельные чекины этого проекта не будут нарушать функционирование системы.

    В противном случае от ветки $/Integration/Main нужно сделать ответвление в $/<имя_данного_командного_проекта>/Development и чекинить в командную ветку. Слияния из командной ветки в интеграционную ветку осуществляем только после того, как проект или итерация будет завершена, т.е. когда будет завершена некоторая целостная порция функционала. Обратное слияние производим ежедневно.

    В случае особой нестабильности разрабатываемого кода в командном проекте можно сделать ветвь разработки $/<имя_данного_командного_проекта>/Unstable. Это ответвление из $/<имя_данного_командного_проекта>/Development. Слияния в $/<имя_данного_командного_проекта>/Development производим, когда некоторый функционал будет готов в ветви разработки. Затем $/<имя_данного_командного_проекта>/Development тестируется и стабилизируется, после чего код перемещается в интеграционную ветвь, где также тестируется и стабилизируется. Обратное слияние производится ежедневно. Однако данный вариант с дополнительным уровнем ветвления следует избегать, поскольку замедляет распространение изменений по дереву ветвей, создает дополнительную работу и повысит вероятность негативного влияния человеческого фактора.

    Минусы подхода со многими командными проектами.

    Изначально придется создать 2 командных проекта "Integration" и "Startup", что противоречит принципу эволюционности информационных систем: "А вдруг кроме этих 2-х командных проектов никаких других создаваться не будет? Вдруг жизнь подскажет, что нужно держаться первого варианта архитектуры расщипляемости проектов".

    В таком случае можно будет пойти таким путем. Изначально заводим командный проект разработки "Startup" с ворк-айтемами и 3-мя ветками кода: Main, Staging, Production. Затем, по окончании проекта Startup и при решении использовать 2-ой вариант архитектуры расщепления проектов (т.е. много командных проектов) делаем следующие действия.
    1) заводим командный проект Integration
    2) делаем слияние из веток Staging и Production в Main
    3) Замораживаем доступ в ветки Staging и Production
    4) Ветку Main переименовываем в Development
    5) В командном проекте Integration делаем ответвление от $/Startup/Development в $/Integration/Main, а оттуда в $/Integration/Staging и $/Integration/Production

    Можно было бы изначально завести командный проект Startup, но потом не заводить командный проект Integration, т.е. в качестве интеграционной ветки использовать Startup, но в этом случае будет логическое нарушение: ворк-айтемы будут только для проекта Startup, а код будет сливаться из всех проектов (в целях интеграции). Поэтому более верно иметь 2 командных проекта Startup и Integration.

    Также в 2005 студии были проблемы с работой из-под некоторого командного проекта с кодом другого командного проекта. Не возникнет ли проблем в TFS 2008/2010, если ворк-айтем относится к одному командному проекту, а связанный чекин производится в код другого командного проекта?

    Достоинство – использование средств TFS по назначению – как задумывалось по концепции, т.к. реальный проект команды (продолжительностью в несколько месяцев, полгода или год) соответствует своему командному проекту, а не странному новообразованию – группе итераций.

     

    Итак, у кого какие мысли? Какой вариант мне использовать? Может быть, кто-то развеет мои сомнения или наоборот укажет на непредвиденные мной грабли/подводные камни? Или может быть кто-то предложит свой вариант?

    Возможно, эта тема уже обсуждалась где-то, и были выработаны грамотные, сбалансированные правила на этот счет? Если да, то кидайте сюда ссылку J

     

    Спасибо!

    • Перемещено SachinW 2 октября 2010 г. 0:59 MSDN Forums Consolidation (От:Visual Studio Team System)
    20 апреля 2010 г. 11:07

Все ответы

  • Привет!

    Если говорить об уже выработанных рекомендациях, то есть целая книга авторства группы Microsoft Patterns & Practices. В русском переводе ее можно скачать здесь:

    http://dev.net.ua/files/folders/tfsguide/entry5771.aspx

    В вашей ситуации я бы не "плодил" несколько team project'ов - поскольку нет легкого способа мигрировать элементы декомпозиции работ (work items) между team project'ами - по крайней мере, в TFS 2008 - то в результате неудобств может оказаться больше, чем выгод. Двухуровневых деревьев итераций и областей должно быть более чем достаточно для организации структурированного хранения элементов декомпозиции работ. В моем случае (один team project на несколько независимых "логических" подпроектов) это прекрасно работает - но, как вы правильно отметили, на всех подпроектах используется примерно одинаковая методология. Если в вашем случае команды будут использовать различные методологии - что, вообщем-то, несколько странно при работе над одним продуктом, но, не мне судить - тогда создание нескольких team project'ов - единственный вариант.

    Что же касается организации ветвления исходного кода, то как раз этот вопрос очень детально освещен в вышеупомянутой книге, поэтому предпочту отослать вас к первоисточнику. Отмечу только, что в рамках одного team project'а можно организовать довольно сложное ветвление исходников.


    Please mark the post as an answer if it does solve the problem. Thanks!
    22 апреля 2010 г. 19:21
  • Дмитро, привет!

    Спасибо Вам за ответ!

    Есть более новая версия вышеуказанной книги. Смотрим тут:
    http://msdn.microsoft.com/ru-ru/default.aspx (см. правую колонку "Бесплатные книги Русского MSDN" -> "Командная разработка с использованием Visual Studio Team Foundation Server")
    Там картинки более качественые, ну и думаю какие-то опечатки исправили, также названия глав чуть-чуть отличаются, т.е. книгу улучшили.
    Хотя суть практически не изменилась. Книга очень хорошо переведена, практически все положения понятны и не вызывают возражений. Так что советую обновить Вашу библиотеку :)
    Точная ссылка:
    http://download.microsoft.com/documents/rus/msdn/TD_whole_w.pdf

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

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

    У меня к Вам вопросы.
    1. Вы на практике использовали такой подход с одним командным проектом на несколько логических проектов?
    2. Вы пользуетесь командными отчетами?
    3. Не вызывает ли нареканий работа с отчетами?

    Кстати, на счет переноса рабочих элементов. Во всё той же книге было написано, что группы рабочих элементов нельзя переносить из одного командного проекта в другой. Зато по одному переносить можно. Подозреваю посредством перетаскивания. Хотя я не пробовал :) Кстати, никто не знает как обстоит дело с переносом рабочих элементов между командными проктами (да и вообще взаимодествие между командными проектами) в TFS 2010?

    И кстати, в этой книге рассматриваются варианты использования отдельного командного проекта для продукта целиком, для каждого нового выпуска, для каждой отдельной команды.
    С другой стороны целую линию продуктов MS выпускала в рамках одного командного проекта:
    http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx

    С уважением,
    Юрий Шпаков

    23 апреля 2010 г. 7:37
  • У меня к Вам вопросы.

    1. Вы на практике использовали такой подход с одним командным проектом на несколько логических проектов?

    Да, именно такой подход используется в настоящее время.

    2. Вы пользуетесь командными отчетами?
    3. Не вызывает ли нареканий работа с отчетами?

    Отчетами пользуюсь достаточно редко: burndown chart я веду в Excel, который интегрируется с TFS через work item query, а если нужно посмотреть статистику по дефектам, то просто выставляю фильтр по нужным итерации и области. Если бы пользовался отчетами более часто, просто сделал бы их копии и настроил нужные значения по умолчанию в фильтрах - благо, опыт создания custom отчетов под TFS имеется.

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

    Возможно, я-таки чего-то не знаю, но мой опыт работы с TFS говорит о том, что само его ядро и API в 2008й версии не предусматривают такой возможности. Копирование (в UI только поштучно) - пожалуйста, а вот именно перенос - увы :(
    С другой стороны целую линию продуктов MS выпускала в рамках одного командного проекта:
    http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
    Ну вот как раз описанный в блоге подход, используемый внутри MS, очень близок к моему видению вопроса. Собственно, как я и сказал в первом посте, единственным оправданием для создания нескольких team projects на один продукт для меня была бы необходимость изоляции на уровне методологий и, как следствие - work item type definitions.
    Please mark the post as an answer if it does solve the problem. Thanks!
    23 апреля 2010 г. 9:09
  • Спасибо большое, Дмитро!

    Вопрос немножко не в тему. Вы пользуетесь Team Build для ASP.NET приложений?

    Меня интересует 2 аспекта:

    1. Непрерывная интеграция (либо ночные билды) -- интересует именно автоматизация (т.е. автоматом, сразу после успешного билда) развертывания результата билда на девелоперский IIS (в частности для автоматической прогонки веб-тестов)

    2. Тут любой из вариантов мне подошел бы:
    2.1 Возможность для успешного билда версии N (точнее сказать для его резултатов) в ручном режиме произвести развертывание на IIS. В идеале открываем список успешных билдов, щелкаем там правой кнопкой, выбираем "Deploy..." и этот билд развернулся на IIS
    2.2 Настроить Build Defenition таким образом, чтобы 1) билды запускались только в ручном режиме, 2) по окончании успешного билда происходило автоматическое развертывание его на IIS (и допустим запуск веб-тестов) -- т.е. вариант 2.2 отличается от варианта 1 только тем, что тригает запуск билда

    Ну и совсем хорошо (это относится ко всем варианта описанным выше), чтобы не только на IIS все разворачивалось, чтобы еще и БД разворачивались или синхронизировали свою схему (допустим на последней итерации добавилост пара таблиц, какое-то поле некоторой таблицы было удалено, а хранимка была изменена).

    Интересуют меня такие вопросы:
    1. Вы с подобного рода задачами сталкивались? Как-то решали?
    2. В VS2010 заявлено, что Web Deployment Projects является устаревшей технологией, а нужно юзать Web Deployment Tool (MSDeploy). Одноко, мне пока не понятно как поженить Team Build и MSDeploy. Какие-т орекомендации по этому вопросу дать можите?

    По поводу того, что WDP устаревшая технолгия написано тут:
    http://blogs.msdn.com/webdevtools/archive/2010/04/14/visual-studio-2010-web-deployment-projects-beta-avail-now.aspx

    Спасибо!

    23 апреля 2010 г. 15:52
  • Добрый день!

    1. Непрерывная интеграция (либо ночные билды) -- интересует именно автоматизация (т.е. автоматом, сразу после успешного билда) развертывания результата билда на девелоперский IIS (в частности для автоматической прогонки веб-тестов)

    Само по себе это не проблема - развертывание прописывается в таргете BeforeTest и выполняется перед запуском тестов (разумеется, если компиляция прошла успешно).  Про таргеты подробно написано здесь: Cusomizable Team Foundation Build Targets

    2. Тут любой из вариантов мне подошел бы:
    2.1 Возможность для успешного билда версии N (точнее сказать для его резултатов) в ручном режиме произвести развертывание на IIS. В идеале открываем список успешных билдов, щелкаем там правой кнопкой, выбираем "Deploy..." и этот билд развернулся на IIS

    Этот вариант я бы, честно говоря, не рассматривал - развертывание на тестовом окружении всегда желательно автоматизировать, да и для добавления пункта Deploy... в контекстное меню билда пришлось бы городить add-in, а то и VSIP-расширение к Visual Studio.

    2.2 Настроить Build Defenition таким образом, чтобы 1) билды запускались только в ручном режиме, 2) по окончании успешного билда происходило автоматическое развертывание его на IIS (и допустим запуск веб-тестов) -- т.е. вариант 2.2 отличается от варианта 1 только тем, что тригает запуск билда

    Ну и совсем хорошо (это относится ко всем варианта описанным выше), чтобы не только на IIS все разворачивалось, чтобы еще и БД разворачивались или синхронизировали свою схему (допустим на последней итерации добавилост пара таблиц, какое-то поле некоторой таблицы было удалено, а хранимка была изменена).

    Интересуют меня такие вопросы:
    1. Вы с подобного рода задачами сталкивались? Как-то решали?

    По пункту 1) - запуск билдов вручную или в режиме Continuous Integration регулируется одной "галочкой" в настройках Build Definition. С этим проблем вообще никаких нет.

    По пункту 2) - в полностью автоматическом режиме на IIS я ничего не разворачивал, но писал PowserShell скрипт, который сам создает application pool, Веб-сайт, виртуальную директорию, копирует в нее файлы и настраивает на созданном Веб-сайте нужную версию ASP .NET. Я думаю, прописать запуск подобного скрипта из MSBuild несложно через ExecTask или что-то подобное. Впрочем, сообществом, помнится, разрабатывался целый пакет расширений для MSBuild - там уже есть готовый набор тасков для работы с IIS, так что с PowerShell даже заморачиваться не придется. С помощью этого же набора расширений можно создавать/удалять базы данных и запускать SQL-скрипты.

    2. В VS2010 заявлено, что Web Deployment Projects является устаревшей технологией, а нужно юзать Web Deployment Tool (MSDeploy). Одноко, мне пока не понятно как поженить Team Build и MSDeploy. Какие-т орекомендации по этому вопросу дать можите?
    Увы, Web Deployment Tool не пользовался - если и расширял Team Build, то на уровне самописных тасков (например, у нас был таск для запуска SourceMonitor и сбора посчитанных метрик кода в специальной базе данных, на которую потом накручивался снова-таки самописный TFS-отчет).
    Please mark the post as an answer if it does solve the problem. Thanks!
    24 апреля 2010 г. 5:51
  • 2.1 - 2.2

    a. Настроить сборку packages в свойствах веб-проекта, на закладках Package/Publish web, Publish SQL

    b. Собрать web-проект через Team Build со стандартным definition, добавив в параметры msbuild /P:DeployOnBuild=true. В output folder появится папка _PublishedWebsites, в ней - готовый к деплою package и скипт для деплоймента.

    с. Настроить lab management для проекта.

    d. Создать второго build definition с шаблоном LabDefaultTemplate. В свойствах процесса можно будет указать первый билд, на закладке build, и скрипт для деплоймента на закладке Deploy. Там же можно прикрутить и веб-тесты.

    Видео по теме: http://microsoftpdc.com/Sessions/FT56 . Подробно показано что и где настранивать, но без использования Lab Management.

    С апгрейдом базы хуже, но тоже можно побороть через database project где-то на этапе до a, и включение полученных скриптов в Package/Publish SQL.

    24 апреля 2010 г. 10:43
    Модератор