Comments 7
У меня есть отличное название для статьи: «Цепочки построений, путь самураев Team Foundation Build». После Build Chain Teamcity, это выглядит ну крайне извращённо :)
Не совсем понимаю. Если у вас два проекта и более, связаны через интерфейсы и IoC какой либо из конфигурации, не имеют ссылок друг на друга прямых, то зачем выполнять какую-то жесткую последовательность?
Если же они имеют прямые ссылки друг на друга, то зачем их разбивать на два отдельных проекта? Проекта каких, TFS? Или вы имеете ввиду вообще все в рамках одного солюшена и проекты обычные?
Какая-то сложная путаница с терминологией. Вы понимаете, что такое контроллер построения? И чем он отличается от Build Definition?
Вот эта картинка что-то вам говорит?
Если же они имеют прямые ссылки друг на друга, то зачем их разбивать на два отдельных проекта? Проекта каких, TFS? Или вы имеете ввиду вообще все в рамках одного солюшена и проекты обычные?
Какая-то сложная путаница с терминологией. Вы понимаете, что такое контроллер построения? И чем он отличается от Build Definition?
Вот эта картинка что-то вам говорит?
>>Если же они имеют прямые ссылки друг на друга, то зачем их разбивать на два отдельных проекта?
>>Проекта каких, 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?
>>Вот эта картинка что-то вам говорит?
Немного не понял, что вы этим хотели сказать.
>>Проекта каких, 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?
>>Вот эта картинка что-то вам говорит?
Немного не понял, что вы этим хотели сказать.
1. Если у вас везде непрерывная интеграция, тогда каким таким образом одни от других могут отстать? И как могут не пройти тесты, если они покрывают (UT) каждый свои проекты? Или вы запускаете какие-то интеграционные тесты, но так их в билде вашем нет. Что-то я все еще не понимаю, зачем вы делаете этот огород.
2. Вы поправили уже, в своей статье, вместо билда говорили контроллер построения, что в корне не верно, это вообще разные вещи.
2. Вы поправили уже, в своей статье, вместо билда говорили контроллер построения, что в корне не верно, это вообще разные вещи.
1. А как по вашему, один командный проект должен узнать об изменении другого? Это и есть часть CI.
2. Опечатки обычно пишут в личку. Спасибо за то, что поправили.
>> зачем вы делаете этот огород.
А какие подходы вы можете предложить?
2. Опечатки обычно пишут в личку. Спасибо за то, что поправили.
>> зачем вы делаете этот огород.
А какие подходы вы можете предложить?
Сразу хочу сказать, что я без каких-то наездов, а то перечитал свои комментарии — как-то грубо и глупо. Извините.
1. Я имею ввиду то, что почему бы их не собирать в одно место, где будут лежать все необходимые актуальные библиотеки?
2. Я посчитал, что это не опечатка, а неправильная трактовка, я догадывался, что вы не можете настраивать так билд контроллер:)
3. Я могу предложить собирать в одну папку, если они у вас связаны всегда или же в разные, если они не связаны, то и не парится по поводу версий. Насколько мне помнится, сейчас к TFS еще привязали специальную часть по деплою и т.д., если я, конечно, с другим продуктом не путаю. Просто сами мы не дошли до этого еще.
1. Я имею ввиду то, что почему бы их не собирать в одно место, где будут лежать все необходимые актуальные библиотеки?
2. Я посчитал, что это не опечатка, а неправильная трактовка, я догадывался, что вы не можете настраивать так билд контроллер:)
3. Я могу предложить собирать в одну папку, если они у вас связаны всегда или же в разные, если они не связаны, то и не парится по поводу версий. Насколько мне помнится, сейчас к TFS еще привязали специальную часть по деплою и т.д., если я, конечно, с другим продуктом не путаю. Просто сами мы не дошли до этого еще.
Sign up to leave a comment.
Последовательности построений в TFS