Управление решением build all в TFS

Question

Я администратор TFS в моей компании. В прошлом я рекомендовал линейную стратегию ветвления для небольших команд, которые также плохо знакомы с TFS. Начните с Dev> Dev слияния до Test> Test слияния до Prod.

Это хорошо работает с решениями, проекты которых являются подкаталогами решения. А как насчет проектов, которые рассредоточены по всему контролю источников?

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

Е.Г.

\ $ TFS \ Dev \ Project1
\ $ TFS \ Dev \ SomeFolder \ Project2
\ $ TFS \ Dev \ SomeOtherFolder \ Project3

У нас есть главный проект, в котором размещены все наши Ассамблеи. Этот проект является проектом "построить все". Он используется с finalBuilder pro для развертывания на следующий уровень. Проблема в том, что эти проекты распространены по всему контролю над источниками. Я не уверен, как управлять ими.

Answer 1

Мое предложение состоит в том, чтобы определить, какие "проекты" выпускаются и версии независимо, и иметь отдельные структуры ветвления для каждого из них.

Вы не хотите иметь 2 независимых проекта (под независимыми, я имею в виду, что они выпускаются / версии отдельно) в одной и той же структуре ветвления.

Типичным способом управления зависимостями между этими проектами является регистрация двоичных файлов из Project 1 версии X в папку Project 2 «lib». Таким образом, вы можете выпускать новые версии Project 1 по своему желанию, но команда Project 2 может решить, когда и если взять зависимость от новой версии.

Если ваши различные "проекты" - это все части одной большой вещи, которая выпущена / версионирована вместе, то я бы порекомендовал просто убедиться, что они все живут в какой-то корневой папке (например, $ \ TFS \ Dev) и ветвятся из есть.

Answer 2

Да.С Team Build вы можете создавать решения не только для разных филиалов, но и для разных групповых проектов.Тем не менее, я думаю, что наилучшей практикой является сохранение каждого проекта и каждой ветви с собственным определением сборки.

В вашем случае, я сначала попытался бы организовать исходное дерево , а затем определитьмастер решение, которое строит все проекты.FinalBuilder должен поддерживать ваш сценарий, хотя я думаю, что FinalBuilder является избыточным, когда у вас есть TFS.