Доброго времени суток.
Я вот хотел бы уточнить пару моментов,касательно этой технологии у тех людей которые использовали(ют) её на работе.
Читал по этому вопросу статью Мартина Фоулера
1.Занимается ли девелопер сборкой всего приложения на своей девелоперской машине для того,чтобы прогнать тесты и решить нужно ли добавлять изменения в репозиторий ?
Большое приложенние может собираться достаточно долго,поэтому может девелопер собирает только отдельные модули приложения и тестирует их ? 
Знакомый мне рассказывал,что он сливает все исходники (~1000 классов),делает изменения и если тесты прошли успешно,записывает изменения в репозиторий.
2.Сколько по максимуму времени девелопер может тратить на сборку и тестирование ?

КАНЕЧНА!!! Мало ли что он там напортачил...



Не исключено. Если система находится не в процессе отладки, а массовой быстрой наработки вороха кода в экстремальном стиле. Но, связи между модулями должны быть весьма прозрачными и слабыми.
Всё равно, желательно прогонять полностью. Но, по кускам иногда тоже оправдано.
Тут решать организатору.
(Кстати, как показывает опыт, люди всё равно будут исподтишка прогонять кусочек и коммитить, а потом делать квадратные глаза "а у меня всё вроде бы работало...   " )
Тут уже надо организационно решать... to beat or not to beat!/ По рукам, ессно 



"Пралльно, дядь Фёдор, бутерброд кушаишшь..."


Вопрос хитрый как мир.
Хорошо если ему хватит две минуты в день без потери качества....
Но... частенько(мягко говоря) нам нужен хороший велосипед, а не самосвал,  который никогда не сможет ездить.
Вопрос так же индивидуален, как критические дни у женщины.
Вот так, наобум говоря, если проект в процессе разработки - то процентов до 50-60 можно.
Если "ждать пока джиюниты прогонятся" - тогда, лучше, конечно до 10-20%.
А когда кодфриз - то можно девелоперов на 100% задействовать в тестировании.

Тесты тестам рознь...

chief39, cпасибо огромное за каменты   !
Сам Continous Integration Server,насколько я понял,занимается сборкой приложения через определённые интервалы времени/по коммиту в репозиторий и предоставлением отчёта о том,что,когда и с каким результатом собралось.Может быть есть что-то еще,что девелоперу необходимо знать про CI ?



Это сообщение отредактировал(а) Greg - 22.12.2006, 22:02

Имхо, эти вещи очень сильно зависят от методологии и инструментария. У нас, например, применяется UCM-модель от Rational, в рамках котороq каждый девелопер/фича имеют разные стримы, которые время от времени сливаются в Integration в полуавтоматичемком режиме.


Предпочтительно - да, но это не всегда возможно. Да и собирать/ставить/конфигурить приложение в нашем случае отнимало бы полдня-день. Нерационально.


В идеале, я считаю, 0. Сборкой должен заведовать отдельный человек, билд-менеджер. Тестирование тоже должно быть только на простую валидацию. Остальное - дело тестеров.

Это тулза конкретного вендора? Такую не пользовал.



Ммм... Спорный идеал.
Билд менеджер должен быть, обязательно. Он заведует сборкой и организацией её процесса. Но не на каждой отдельно взятой машине.



Разрабатываю, к примеру, я модуль "ПурПырБурМация".
Он должен ПурПырБурировать и ПурПырБурМировать.

Написал некий кусок его.
Коммичу.
Валится.
На сервере.
Бьют меня вдесятером.
Час ждут пересборки на сервере.
Исправляю - тестер ругается - НуллПойнтер у меня

А почему валится? Потому что я не сделал:
Собрать у себя локально проект с моим модулем - сборка ОК.
Запустить юнит-тесты - юнит-тесты ОК.
Прогнал свою бизнес-логику - работает. И, вроде бы, корректно.
То что работает - это уже тестер без нуллпойнтеров.
То что вроде бы, и кажись на сотую процента результат отклоняется  - это уже действительно дело тестера.

Ну и, плюс, тестеров я различаю.
Есть те, которые могут ревьюить архитектуру, реализацию, код, писать сложные автоматические функциональные тесты, писать джиюнит тесты на роль use-case(то ест ьзакодированные уже бизнес-требования). Но их все считают разработчиками... Потому что тестер - это немодно.
И есть те, кто тыкает непонятные кнопки и когда видит непонятную надпись, кричит: Коля!!! Саша!!! У меня тут кошмар!!!

Ну, в принципе, наши точки зрения не расходятся 

Да они уже давно все в QA-инженеров переименовались 

Вытащил всё-таки на свет термин 

Я тут без штампов пытался... 

Нет,это не тулза а название для абстрактного сервера интеграции   

Хм.. хм..
А если опять какая-нибудь детская ошибка вылезет,исправлять и ещё один час ждать ?
До этого мне представлялось,что целесообразно сначала прогонять jUnit тесты для той части приложения,за которую отвечает девелопер (их пишет сам девелопер) и,в случае успеха,сборка всего приложения и прогонка тестов по всему приложению.
Первая часть по времени не должна занимать много.И если она завершится успешно - то во вотрой части получение ошибки менее вероятно.

Это смотря какая методология используется.

А какие есть?

batigoal,  ну к примеру TDD - Test Driven Development, как видно из названия, разработка управляется тестами и тестеры нужны только для тестов уже более-менее готовых вещей. Unit тесстами занимаются непосредственно разработчики.