Организация работы с TFS

[Александр Пчелин]

Сейчас у нас TFS используется только как хранилище последней версии
продукта.
Eсть два командных проекта (условно TP1 и TP2), который никак не
пересекаются.

Что хочется сделать:
1. Вынести общий код и скомпилированые внешние сборки в командный
проект Common
2. Вынести WCF-сервисы в командный проект WCF
3. Организовать раздельное хранение Dev и Main кода.
4. Организовать работу с общим кодом.

Что я сделал:
Пункты 1-3 проблем не вызвали, а вот с 4 все плохо.
Пример использования для реализации задачи Feature1:
$Common/Main/Source -> $WCF/Main/Source/Common
$Common/Main/Source -> $TP1/Main/Source/Common
$WCF/Main/Source -> $TP1/Main/Source/WCF
$TP1/Main/Source -> $TP1/Dev/Feature1
Сценарии:
1. При реализации задачи Feature1 возникла необходимость внести
изменения в код проекта WCF, которые повлекли за собой изменения
Common. Как правильно должны вноситься эти изменения.
2. При реализации Feature1 возникла необходимость добавить новую
скомпилированую сборку в Common. Куда и как её добавлять?

Вообщем очень нужна помощь.
Заранее спасибо!

[Alexey Petriashev]

У нас используется такая система:
Проекты организованы так:

Физическая структура проекта:
TeamProject
    build         : сборочные скрипты
    lib            : библиотеки
    common    : здесь лежат бинарники общих компонентов
    src            : исходники проектов
    tools        : инструменты, например NAnt
    TeamProject.sln
   
Логическая структура в TFS без бранчей:
$TeamProject
    build
    lib
        Nunit-2.5.8
        Log4net-1.2.10
    common
        Component1    : это бранч от $SharedComponents/Component1/bin
        Component2    : это бранч от $SharedComponents/Component2/Main/bin
    src
        TeamProject.Core
        TeamProject.BlaBlaBla
    tools
    TeamProject.sln
    SomeElse.sln
   
Логическая структура в TFS c бранчами:
$TeamProject
    Dev
        build,
        lib
            Nunit-2.5.8
            Log4net-1.2.10
        common
            Component1    : это бранч от $SharedComponents/Component1/bin
            Component2    : это бранч от $SharedComponents/Component2/Dev/bin
        src
        tools
        TeamProject.sln
        SomeElse.sln
    Main
        build
        lib
        common
            Component1    : это бранч от $SharedComponents/Component1/bin
            Component2    : это бранч от $SharedComponents/Component2/Main/bin
        src
        tools
        TeamProject.sln
        SomeElse.sln

Логическая структура общих компонентов в TFS:       
$SharedComponents
    Component1 (без бранчей)
        bin        : здесь хранятся скомпилированные бинарники
        build    : здесь скрипты для сборки bin
        lib
        src
    Component2 (с бранчами)
        Dev
            bin, build, lib, src
        Main
            bin, build, lib, src
           
Процесс работы с общими компонентами:

Использование:
Нужно отбранчевать папку bin нужного компонента в папку проекта common/ИмяКомпонента,
например $SharedComponents/Component1/bin -> $TeamProject/common/Component1

Обновление компонента в зависимом проекте:
Нужно слить папку bin компонента в папку проекта common/ИмяКомпонента (merge,checkin)
$SharedComponents/Component1/bin ->  $TeamProject/common/Component1

Работа с общим компонентом:
- Добавление фичи
- тестирование, сборка
- обновление папки bin
- можно повесить Label, чтобы потом можно было вытащить исходники или бинарники нужной версии.

Что мы получаем:
- Такая система позволяет независимо работать над компонентами и проектами, которые из используют.
- Различные проекты, кроме того могут использовать различную версию общего компонента.
- Проект сам решает, когда ему обновить версию компонента (новая версия компонента может сломать существующий оттестированный функционал)
- Все проекты являются независимыми единицами. Такие проекты можно забрать на любую машину с использованием простого биндинга и все должно собираться и работать. Это нужно, например, для Continiuos Integration

[Александр Пчелин]

Не понял, как в $TeamProject связаны Dev и Main.

Если Dev является бренчем от Main, то как решается Конфликт с common/Component2 при мерже?

24 марта 2011 г. 16:44 пользователь Alexey Petriashev <petri...@gmail.com> написал:

--
С уважением, Александр Пчелин.

[Алексей Петряшев]

Тут возможны разные варианты. В MSDN есть статья про различные сценарии работы с бранчами.
Например: Main - стабильная ветка, Dev - это бранч от Main.
Лучше, конечно ссылаться на одну версию компонента (стабильную Main)
Еще один вариант - это использовать версии как в lib.
Например:
common
   Component-0.2
   Component-0.3
Тогда конфликтов не будет, так как на уровне проекта указана конкретная версия.

24 марта 2011 г. 17:00 пользователь Александр Пчелин <a.pc...@gmail.com> написал:

[Александр Пчелин]

По вашей структуре структуре TFS, как я понимаю, если в рамках работы над $TeamProject необходимо доработать что-либо из $SharedComponents, то это делается в двух разных проектах.

 

У нас требование скорее такое, во всех TeamProject'ах должны быть актуальные сборки из Common. Сейчас в солюшен добавляется реальный проект из бренча Common. Т.е. $TP1/Dev/Feature1/Source/Proj.sln содрежит ссылку на $TP1/Dev/Feature1/Source/Common/Common.csproj

 

24 марта 2011 г. 17:15 пользователь Алексей Петряшев <petri...@gmail.com> написал:

[Alexey Petriashev]

Почему в двух? в одном: в SharedComponents
потом изменения проталкиваются в зависимые проекты.
Что значит актуальная версия компонента? У вас десяток проектов, которые используют общий компонент. Для последних двух вам понадобилось изменить шаренный компонент. Если вы затянете изменения во все проекты, то возможно сломаете что-то. Проекты, которые устраивает старая версия - пусть работают на стррой версии - они протестированы и отлажены именно на той версии. Если обновлять версию компонента, то нужно заново проводить тестирование проектов, возможно исправление ошибок, потом снова тестирование и все такое.

Добавление исходников я бы порекомендовал только на стадии интенсивных доработок компонента, пока он не придет в стабильное состояние. Потом лучше подключать его бинарниками. Когда в вас в решении более 40 проектов, что Вы меня поймете! ))

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

[Alexey Petriashev]

Есть еще один вариант - может он Вам продойдет:
$TeamProject
  libs
  Project1
  Project2

Тогда проекты могут использовать заведомо одну версию библиотек.
 

[Александр Пчелин]

Собственно последний из предложенных вами вариантов у нас и используется, хотелось все привести в какой-то относительный порядок.

Завтра попробую привести все к варианту с использованием ссылок на готовые библиотеки.

Спасибо за помощь!

 

P.S. Хотелось бы еще от кого-нибудь услышать о стратегии использования TFS.

24 марта 2011 г. 17:46 пользователь Alexey Petriashev <petri...@gmail.com> написал: