Извините за длительное молчание.
Мы собираем в одно место. Это может быть как локальная(сетевая папка) так и Nuget сервер.
Нам просто так удобно собирать рабочую версию.
>>Если же они имеют прямые ссылки друг на друга, то зачем их разбивать на два отдельных проекта?
>>Проекта каких, TFS? Или вы имеете ввиду вообще все в рамках одного солюшена и проекты обычные?
Для проекта «Assembly1» настроено два построения: «ClassLibrary1» и «ClassLibrary2».
Для проекта «Assembly2» тоже настроено два построения: «A2.t2» и «A2.t3».
Проект «Assembly1» это Team project (в терминологии TFS), проект «Assembly2» тоже Team project (просто они так называются).
Они могут состоять из произвольного числа проектов (в терминологии Visual Studio).
Построения «ClassLibrary1» и т.д. является «Build Definition».
>>Не совсем понимаю. Если у вас два проекта и более, связаны через интерфейсы и IoC какой либо из конфигурации,
>>не имеют ссылок друг на друга прямых, то зачем выполнять какую-то жесткую последовательность?
1. Например, если есть базовая часть и дополнительные модули, которые находятся в разных командных проектах и требуется иметь Release версию, то удобно будет запустить одно построение а не N.
2. В базовой части могут произойти большие изменения, из-за которых могут перестать работать другие модули, но вы об этом не узнаете.
Т.к. у вас будет один зелёный флажок от базовой части, остальные модули не будут перестроены и соответственно не будут выполнены тесты.
>>Вы понимаете, что такое контроллер построения? И чем он отличается от Build Definition?
>>Вот эта картинка что-то вам говорит?
Как самого «камня», так и системника в сборе.
Мы собираем в одно место. Это может быть как локальная(сетевая папка) так и Nuget сервер.
Нам просто так удобно собирать рабочую версию.
2. Опечатки обычно пишут в личку. Спасибо за то, что поправили.
>> зачем вы делаете этот огород.
А какие подходы вы можете предложить?
>>Проекта каких, TFS? Или вы имеете ввиду вообще все в рамках одного солюшена и проекты обычные?
Для проекта «Assembly1» настроено два построения: «ClassLibrary1» и «ClassLibrary2».
Для проекта «Assembly2» тоже настроено два построения: «A2.t2» и «A2.t3».
Проект «Assembly1» это Team project (в терминологии TFS), проект «Assembly2» тоже Team project (просто они так называются).
Они могут состоять из произвольного числа проектов (в терминологии Visual Studio).
Построения «ClassLibrary1» и т.д. является «Build Definition».
>>Не совсем понимаю. Если у вас два проекта и более, связаны через интерфейсы и IoC какой либо из конфигурации,
>>не имеют ссылок друг на друга прямых, то зачем выполнять какую-то жесткую последовательность?
1. Например, если есть базовая часть и дополнительные модули, которые находятся в разных командных проектах и требуется иметь Release версию, то удобно будет запустить одно построение а не N.
2. В базовой части могут произойти большие изменения, из-за которых могут перестать работать другие модули, но вы об этом не узнаете.
Т.к. у вас будет один зелёный флажок от базовой части, остальные модули не будут перестроены и соответственно не будут выполнены тесты.
>>Вы понимаете, что такое контроллер построения? И чем он отличается от Build Definition?
>>Вот эта картинка что-то вам говорит?
Немного не понял, что вы этим хотели сказать.