Коллеги, не подскажете ли какую доходчивую статейку про настройку на TFS непрерывной интеграции?
Требования самые обычные: настроить билд-сервер, который будет запускать перед check-in скрипт MSBuild, прогоняющий тесты и выполняющий check-in только при успешном прогоне.

Здравствуйте, akarinsky, Вы писали:

A>Коллеги, не подскажете ли какую доходчивую статейку про настройку на TFS непрерывной интеграции?
A>Требования самые обычные: настроить билд-сервер, который будет запускать перед check-in скрипт MSBuild, прогоняющий тесты и выполняющий check-in только при успешном прогоне.
А Вы точно этого хотите? Вы работаете с TFS? А с Build Server? Что-то мне подсказывает, что нет...

Здравствуйте, Аноним, Вы писали:

телепат?

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>телепат?

А>да, TFS. пока используется только как система контроля версий, но хочется большего.
Только учюсь
Попробуйте настроить и запустить Build Server и Вам станет ясно, что так не получится
Во-первых, Build server работает на сервере (извиняюсь за тафталогию) — т.е. при запуске билда сначала закачиваются файлы из БД в директорию сервера, а потом запускается билд (сам по себе не быстрый ). В процессе билда TFS бежит по всем таскам/багам и меняет у них волшебную цифирь . Если разработчик подписан на отсылку почтового сообщения о изменении таска/бага — очень интересно наблюдать за разработчиками, когда они начинают получать по 1000 писем
У нас средний проект(основной), который включает в себя порядка 100 под-проектов — сборка батником составляет порядка 10 мин, посредством Build Server — около полутора часов...

Мой Вам совет — бегите от TFS пока не поздно

Здравствуйте, akarinsky, Вы писали:

A>Коллеги, не подскажете ли какую доходчивую статейку про настройку на TFS непрерывной интеграции?
A>Требования самые обычные: настроить билд-сервер, который будет запускать перед check-in скрипт MSBuild, прогоняющий тесты и выполняющий check-in только при успешном прогоне.

Согласен с Анонимом. Билд сервер не увидит ваши изменения, пока не выполните check-in.

можно попробовать замутить с бранчами. Т.е. делаете check-in в неосновной бранч, после того как билд сервер его сбилдит, мержить в основной.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>У нас средний проект(основной), который включает в себя порядка 100 под-проектов — сборка батником составляет порядка 10 мин, посредством Build Server — около полутора часов...

А>Мой Вам совет — бегите от TFS пока не поздно

Согласен. Имею аналогичный опыт работы с TFS. Билдим батником, правда завернутым в С++ проект, так что все ошибки и ворнинги видим прямо в среде.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, akarinsky, Вы писали:

A>>Коллеги, не подскажете ли какую доходчивую статейку про настройку на TFS непрерывной интеграции?
A>>Требования самые обычные: настроить билд-сервер, который будет запускать перед check-in скрипт MSBuild, прогоняющий тесты и выполняющий check-in только при успешном прогоне.

S>Согласен с Анонимом. Билд сервер не увидит ваши изменения, пока не выполните check-in.

S>можно попробовать замутить с бранчами. Т.е. делаете check-in в неосновной бранч, после того как билд сервер его сбилдит, мержить в основной.
Нет, если хотите вязать нормальные полиси (а не те, которые есть у TFS) — Вам прямая дорога в бат и скрипт кодинг

Здравствуйте, Аноним, Вы писали:

Какая жуть... Спасибо за предупреждение.
Буду настраивать Cruise Control.

Здравствуйте, samius, Вы писали:

S>можно попробовать замутить с бранчами. Т.е. делаете check-in в неосновной бранч, после того как билд сервер его сбилдит, мержить в основной.
Вот так же мы с админом когда-то настраивал сценарий Cruise Control.
Т.е. CC тянул из SVN из персональных веток последнюю версию, потом мержил их в build-ветку, потом билдил, запускал тесты, всякие утилиты типа сбора метрик, и
если все в порядке — мержил билд-ветку с транком, откуда в персональные ветки разработчиков выполнялись апдейты.

Здравствуйте, akarinsky, Вы писали:

A>Коллеги, не подскажете ли какую доходчивую статейку про настройку на TFS непрерывной интеграции?
A>Требования самые обычные: настроить билд-сервер, который будет запускать перед check-in скрипт MSBuild, прогоняющий тесты и выполняющий check-in только при успешном прогоне.

Они это преподносят как уникальную фичу. TFS на мой взгляд хорош только как сорс контрол, все остальное в нем убого и морально устарело еще до момента релиза. Проверку check-in'a я видел только в TeamCity. Оч советую посмотреть тимсити, обеспечивает все что нужно от билд сервера. Но даже в нем чтобы проверить чекин, юзер должен сам это потребовать, т.е. "прогони билд и если все ок — вчекинь". Проверять все чекины это не очень хорошее решение — придется городить несколько веток и стэйт на момент успешного билда переносить в отдельную ветку, при этом получится что чекинит в нее только билд сервер и понять кто какие изменения сделал невозможно. Правильней иметь несколько билдов (release, nightly, after checkin) и поставить на широкую ногу систему раздачи "подарков" тем кто заваливает билд и не чинит , тот же тимсити предоставляет кучу способов оповещения (почта, жаббер, иконка в трее) плюс есть фича "взять ответственность за сломанный билд на себя". На сколько я понимаю идея проверки возникла с тем чтобы иметь всегда рабочую версию кода , можно настроить паблишинг не только результатов но и исходников из которых они были собраны или ставить лэйбл в сорс контроле.

Здравствуйте, akarinsky, Вы писали:

A>Коллеги, не подскажете ли какую доходчивую статейку про настройку на TFS непрерывной интеграции?
A>Требования самые обычные: настроить билд-сервер, который будет запускать перед check-in скрипт MSBuild, прогоняющий тесты и выполняющий check-in только при успешном прогоне.

В данном случае нет необходимости использовать непрерывную интеграцию. Можно создать политику возврата (check-in policy), которая при каждом check-in будет выполнять необходимые тесты, если тесты не прошли — check-in не будет выполнен.

A>В данном случае нет необходимости использовать непрерывную интеграцию. Можно создать политику возврата (check-in policy), которая при каждом check-in будет выполнять необходимые тесты, если тесты не прошли — check-in не будет выполнен.

м-м-м... а нет ли ссылки на примерчик какой?

Здравствуйте, akarinsky, Вы писали:

A>м-м-м... а нет ли ссылки на примерчик какой?

И примерчик дадим Как включить проверку на выполнение тестов при возврате изменений в TFS