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

Существует довольно много различных сред непрерывной интеграции (CI), и мне интересно, какая из них наиболее популярна. Какие рамки вы использовали в фирмах, где вы работаете?

Есть ли какая-то причина, по которой одна инфраструктура CI более популярна, чем другая - возможно, это связано с функциями, которые она предлагает, вещами, которые интегрируются в нее, или, может быть, это просто маркетинг?

Кажется, что непрерывная интеграция используется больше в мирах Java и .net, чем, скажем, ruby ​​или python. Почему это?

Хадсон или Дженкинс (последний является вилкой первого). Причина: он прост (прост в установке и использовании) и обладает большой гибкостью. Плагины добавляют почти все функции, которые я могу придумать.

Несколько лет назад я использовал урон от повреждений . Он также был прост в использовании, но не имел плагинов. Но автор решил, что он откажется от простого решения, и начал разработку новой версии, состоящей из разных серверов, взаимодействующих друг с другом (какого черта?). Это не сработало, и проект был сдан. Некоторое время я был в поиске, но ни круизконтроль (слишком сложный), ни континуум действительно не помогли мне. До Гудзона, это работало с первого момента для меня.

Я использую TeamCity на работе и дома. Он имеет отличную поддержку для различных сборщиков и расширяется с помощью плагинов.

Не иметь дело с кучей XML для конфигурации - огромный плюс в моих книгах, и бесплатная версия достаточна для моих домашних нужд.

Одна из проблем, с которой я столкнулся в TeamCity, связана с попыткой автоматически установить версии сборок .NET. Мне пришлось создать относительно сложный обходной путь, но как только он был на месте, он работал как шарм.

Лично я когда-либо использовал только CruiseControl и CruiseControl.Net. Причина этого связана с экономикой. Они достаточно стабильны, и как только вы их настроите, вам мало что нужно будет сделать, чтобы сохранить их. Сообщество пользователей обычно очень полезно, и оно может быть расширено для ваших нужд.

Тем не менее, есть несколько коммерческих предложений, которые мне известны (одно от JetBrains, другое от Atlassian), которые предлагают лучший опыт настройки и коммерческую поддержку. Я хотел попробовать эти предложения, но на самом деле еще не было возможности.

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

Существует три основных класса проблем, которые инструменты CI могут вам помочь:

1. Ошибки компиляции - если сигнатура класса изменяется таким образом, что нарушает зависимости, лучше знать об этом до наступления часов доставки.
2. Логические ошибки - если поведение класса изменяется таким образом, что нарушает зависимости, лучше знать об этом заранее. Это должно быть проверено каким-то автоматическим тестированием, чаще всего модульным тестированием.
3. Приемочное тестирование - если у вас есть автоматизированный набор тестов для запуска готового продукта, лучше запускать их часто.

Интерпретированные языки не компилируются, поэтому нет ошибок компиляции. Однако две другие проблемы достаточно распространены, так что инструменты CI полезны для проектов в Ruby / Python / Perl / etc.

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

редактировать

Смотрите этот хороший график для сравнения функций большого количества инструментов CI (о многих из которых я не знал):

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

Team Foundation Server

Твердый CI, тесная интеграция с Visual Studio и Git в качестве контроля версий . Я видел более гибкие CI-серверы, такие как Hudson, но тесная интеграция TFS с другими продуктами делает процесс настолько плавным, что это просто имеет смысл для моей команды.

Я использую как CruiseControl.NET, так и Hudson . Некоторые из моих сборок находятся на одном из них, а некоторые на другом.

Зачем? Потому что я не инженер по сборке, а тот, кто является инженером по сборке, настроил их таким образом!

У меня нет проблем с настройкой моих сборок или жалоб на какой-либо продукт. Я сообщаю вам о том, как обстоят дела, и надеюсь, вы оцените эту перспективу!

ОБНОВЛЕНИЕ: так как я отправил ответ, Хадсон был раздвоен и стал Дженкинс . Приведенная выше рекомендация относится к Дженкинс.

Пульс . Это в основном Just Works, что для занятого инженера по сборке является большой проблемой. У них также есть действительно превосходная техническая поддержка. Основная причина, по которой я его так люблю, состоит в том, что у нас более 250 проектов, и они справляются с ними без сбоев; Я не могу сказать то же самое для Гудзона.

Наша команда работает в основном на Python, C ++ и Java. Мы используем Buildbot для CI. Мы изначально начали с него, потому что он интегрируется с Trac и потому что он казался простым и понятным. Я считаю, что это предпочтительная структура CI в мире Python.

Хадсон. Временами он немного глючит, и некоторые из более интересных плагинов на самом деле не работают, но с небольшим количеством рук это довольно удобно.

Я бы, вероятно, использовал вместо этого Pulse, но если вам нужно собрать на нескольких платформах, это> $ 5k, что немного.

CruiseControl.NET для непрерывной интеграции. Работает довольно хорошо, хотя с очень большим количеством сборочных проектов, которые мы настроили в CruiseControl, приложение CCTray для настольных лотков ужасно не реагирует даже на большие интервалы обновления.

NAnt предназначен для сценариев сборки, которые выполняются в проектах CruiseControl. Для более сложных сценариев сборки мы расширили NAnt с помощью пользовательских задач C # NAnt, что очень приятно - писать код на C # гораздо приятнее, чем создавать сценарии NAnt.

Мы являемся магазином Microsoft и теоретически перейдем на Team Build 2010 после того, как перенесем среду Team Foundation Server на 2010 год.

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

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

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

Обратите внимание, что взаимозаменяемость подразумевает, что не имеет значения, на каком языке они написаны. Я полагаю, что Java была выбрана для многих движков, потому что поддерживается много платформ в сочетании со многими легкодоступными строительными блоками. Нужен веб-сервер - захватите один. Нужно много одновременных потоков - просто используйте их. Нужна расширяемость - капля в банку.

Прежде чем я услышал термин «непрерывная интеграция» (это было в 2002 или 2003 году), я написал сценарий ночной сборки, который подключался к cvs, взял чистую копию основного проекта и пяти меньших подпроектов, собрал все jars via ant затем создает и повторно развертывает WAR-файл с помощью второго ant-скрипта, который использует задачи tomcat ant.

Он работал через cron в 7 вечера и отправил электронное письмо с кучей прикрепленных выходных файлов. Мы использовали его в течение всех 7 месяцев проекта, и он оставался в использовании в течение следующих 20 месяцев технического обслуживания и улучшений.

Он работал нормально, но все же предпочитал hudson сценариям bash, cron и ant.