Что вы используете для Continuous Integration?

[mark_ablov]

свой лисапед, куда же без него :)

[BurundukXP]

из-за чего свой мастерить стали, а не использовали какое-нибудь готовое решение?

[Mel]

Используем Buildbot

[Outspector]

Jenkins, который у нас появился под впечатлением от статьи "Непрерывное тестирование питонопроекта" на хабре. До этого мы отлынивали от запуска тестов после внесения изменений в код, из-за чего больше половины из их тупо не проходило. Сейчас всё выглядит красиво, и тестирование наконец-то превратилось в полезный инструмент отлавливания неочевидных ошибок.

[prodmitry]

А почему в списке нет TFS Build? Вроде частенько используется…

[BurundukXP]

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

[lair]

Вот да, я тоже удивлен.

[outcoldman]

Кто выбрал «Работаем без Continuous Integration», ответьте: почему?

[LighteR]

Скорее всего, потому что тесты не пишут.

[outcoldman]

+ не используют репозитарии, не компилируют код, вообще, ну и никогда не собирают проекты совсем.

[alexs0ff]

>>никогда не собирают проекты совсем
Это верно для маленьких проектов, в реальности в больших приложениях сборкой не занимаются рядовые программисты, для этого существуют специальные люди -билд-инженеры, они как раз разруливают все зависимости и настройки среды.

[outcoldman]

Именно! Они настраивают билд серверы, которые являются частью Continuous Integration.

[aavezel]

В CI тесты, кстати не главное. CI как средство CD (Continuous Development) очень действенная штука…

[lair]

Вообще-то, CD — это continuous delivery, а не development (а development — он почти всегда continuous).

[alexs0ff]

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

[Ex3NDR]

А где связь?

[outcoldman]

Извините, что так грубо, но «Что за бред вы несете?». Причем тут Agile и Continuous Integration? Ну и для меня не очевидно «они используют другие методологии проектирования отличные от Agile».

[alexs0ff]

как причем? Использовать непрерывную интеграцию целесообразно только в проектах с гибкой(Agile) методикой, где присутствуют итерации. В проектах которые пишутся по методике «Четкого Планирования», т.е. сначала пишем подробное Т.З. делаем и отдаем заказчику, в таких случаях непрерывная интеграция отсутствует. Где тут «неочевидные» вещи?

[outcoldman]

Точно, открыли глаза! Поясню для остальных. При водопадной модели дело происходит, примерно, так. Каждый разработчик держит исходники у себя (никто не билдит, никаким тестерам ничего не отдают!), потом по окончании времени кодирования все сабмититься в репозиторий (и то не обязательно), один из разработчиков берет на себя ответственность по объединению и билду (билдить можно только один раз!). После того, как все сбилдилось, начинается тестирование. Находятся баги и просто записываются куда-нибудь, все равно их править никто не будет, запускать этот аггрегат опять (тот разработчик, который все объединял уже поседел) никто не хочет. Если количество багов превышает строк кода, то проект считается проваленным. В остальном случае все хорошо, отдается заказчику.

Я все правильно понял, что такое не Agile?

Или серьезно, что при использовании «не гибких методологий» не нужно готовить площадки для тестирования, не нужно следить за качеством кода и т.п.?

[alexs0ff]

Не пойму Вашего «сарказма». Интеграция всего кода это отдельный процес при waterfall методики, почитайте википедию:

После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов

т.е. интегрируют между собой уже после того как написали. А применения средств из гибких методологий, в т.ч. непрерывной интеграции это уже от лукавого, если чувствуете необходимость — тогда переходите полностью на Agile.

[outcoldman]

мне кажется, что вы просто не понимаете что такое Continuous Integration, либо я не понимаю, что вы хотите сказать. Ну никак Continuous Integration не завязано на Agile, да и вообще на какой-нибудь технологии.

[tampere]

Билдить не «можно один раз», а «необходимо один раз». Никто не мешает собирать по ходу, и это не обязательно называть модным словом «agile».

[andrewsch]

У нас руки просто не доходят настроить, а так все есть — и артефакты, и юнит тесты.

Просто настройка CI это дофига работы и плясок с бубном вокруг. С ограниченными ресурсами просто не до того. А в маленькой команде и так можно обойтись.

[aavezel]

Дак не пишите свою CI, лучше воспользоваться готовой. А любая CI настраивается профессионалом за час, непрофессионалом за день…

[andrewsch]

Дык ведь не совсем. В моем случае нужно окружение настроить и базу накатить подходящую и кучу сервисов поднять. А команда распределенная и выделенного сервера под CI пока нет (а тот что с контролем версий — билд не потянет, точнее юнит тесты будут слишком долго 100% CPU грузить). И создавать окружение для CI билда на моей машине, чтобы она не конфликтовала с моей средой разработки — геммор. Так что в час или день я не впишусь. А недели-двух на это пока нет. Проще вручную тесты прогнать (я это так или иначе делаю постоянно). И это в маленькой компании.

А в паре средне-маленьких компаний, где я был (до 100 человек RnD), так там на ночные билды и тесты (до CI даже не доходило) на полную ставку работал один или несколько человек.

Так что на эти дела времени и денег немало уходит.

[aavezel]

Вы неверно понимаете смысл CI. Билд в CI должен собираться не больше 5-10 минут. То что вы говорите это «ночные» (приёмочные) тесты. И собираются они по расписанию, а не по сдаче. Хотя они и могут сидеть на CI…

[aavezel]

Неверно выразился. Ночные сборки это часть CI, но не его главная и основная часть.

[andrewsch]

Ок, у меня билд без юнит тестов будет собран действительно за минуту-две. И чисто билд я действительно могу загнать в CI за час или за день. Ну пользы от него без юнит тестов я мало вижу, поэтому и не вожусь. Тем более если оно будет у меня на машине висеть в бэкнраунде и произвольно проц пригружать. Когда будет выделенный сервер, тогда я уже ночными/периодическими сборками полноценно займусь — с тестами оно интереснее.

А второй мой случай — там билд, это запуск штук 20-30 паралелных билдов на разных платформах, каждый из которых занимает от получаса до 4-5 часов (старые платформы жутко тормозят). Так там надо всю сеть и парк машин под это дело освобождать. Так что реализация CI там требует пересмотра всего процесса сборки — что означает несколько человеко-лет работы.

Но это я так, жалуюсь :-) на самом деле мы тоже стремимся в светлое будущее :-)

[aavezel]

Для этого есть разделение на быстрые и долгие тесты. Быстрые прогоняются при сдаче, долгие при ночной сборке…

Кстати, некоторые долгие тесты, при правильном использовании mock, либо при оптимизации развёртывания среды (копирование файлов базы, вместо развёртывания backup; использование чистых виртуалок в hypernate) зачастую переходят в разряд быстрых. Но это я так хвастаюсь/делюсь информацией ;-)…

[andrewsch]

Если вы про мой второй пример, то время билда до 4-5 часов — это только билд, без юнит тестов… я-бы и рад короткие юнит тесты использовать, а толку?..

[mezastel]

выделенного сервера под CI пока нет

так купите, проблем то… :)

[andrewsch]

как только заработаем :-)

[bagyr]

Подтверждаю. Если все в VCS и на тестах, то с 0 до рисующего что-то TeamCity — один системник и неторопливый человеко-день. А еще это дело очень любят всякого рода непрофильные начальники и продажники.

[outcoldman]

Я прочитал практически весь ваш диалог вниз. Слушайте, ну могу только одно посоветовать — CI реально влияет на качество и своевременность, ну и на время реагирования. В общем, лучше уж потратить время и деньги, и сделать. Все-таки, за 8 тыщ можно уже что-то купить (и даже меньше), а это не такие уж и большие деньги.
Я просто недавно был в такой компании, в которой не было CI с билд сервером, я просто поэтапно начал требовать и показывать зачем это нужно (тупо сначала установив его у себя на машине), давил таким образом на руководство.

[ixSci]

Многие считают это лишней тратой времени и сил. «Зачем нам это, без него же все работает!»

[rengo]

Конечно же TFS! ))

[netslow]

А теперь главный вопрос — кто использует эти продукты действительно как CI сервер, а не как сервер сборки?

[Ferroman]

Я

[camperov]

TeamCity есть, но по большому счету не юзаем. Только email-ы о неудавшихся билдах рассылаются.

[casey]

Обхожусь юнит-тестами при рефакторинге и перед установкой тэгов

[Osaka]

Пожалуйста, учитесь строить опросы статистически верно. Я вот очень хотел нажать «Работаем без Continuous Integration» вместо «Воздержаться», при том что я понятия не имею, что это такое (потому что никак не связан с разработкой ПО). Ведь я правда работаю без него…
Если вместо «Работаем без Continuous Integration» писать «Разрабатываем ПО без использования Continuous Integration», такого соблазна не будет.

[BurundukXP]

ок, учту, если когда-нибудь еще соберусь сделать опрос.

[ice9]

Просто не участвуйте в опросах, если понятия не имеете, о чём они, и никаких соблазнов не возникнет.

[divanikus]

Юзаем CruiseControl.NET, ибо тащить яву для сборки виндовых приложений под винду было… неохота. Правда с внедрением настоящего тестирования так и не продвинулись, увы.

[kmike]

При выкатывании изменений просто запускаются тесты на сервере (тем же скриптом, что и локально), никаких инструментов не используется — это тоже CI?

[sparhawk]

Continuous Integration в первую очередь преследует цель котнроля качества ПО и гарантирует, что новая версия продукта
1) может быть без проблем собрана и готова к установке/обвнолению,
2) удовлетворяет требованиям, заложенным в автотесты.
Под новой версией подразумевается текущая разрабатываемая версия (trunc, head и т. п.).
Часто разработчик не может проверить эти два пункта перед каждым коммитом.
Continuous Integration отлично вписывается в Agile, который не выделяет времени в конце итерации на приведение продукта в божеский вид :)

[m_a_d]

Я не минусующий, но попробую. Результат сборки на CI-сервере за счет среды может отличаться от локальной на рабочем месте разработчика. И проходить тесты эта сборка тоже может по-другому. Многое здесь конечно определяется платформой разработки. Если говорить про c++ в винде, то могут различаться версии подключаемых библиотек и т.д., и т.п. Соответственно, у одного разработчика все тесты пройдут, он радостно закоммитит, а у второго после апдейта проект вообще может не собраться. Вот для этого и используется CI — как общий знаменатель.

[st3]

Используем Jenkins (Hudson), уже с 25ю сборочными стендами — полет отличный.
Куча готовых плагинов, хороший API.

В сравнении с CruiseControl (не .net) — небо и земля.

[catlion]

Ответил CruiseControl, на самом деле .NET его реинкарнация.

[1nd1go]

Bamboo vs hudson — можете объяснить почему предпочтительнее бамбу? У нас на разных проектах и то и т нормально пахало, сейчас надо вотвыбрать один и их.