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

21

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

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

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

Ричард Уорбертон
источник
Одна из причин, почему CI не так важен для Ruby и Python, заключается в том, что языки интерпретируются, поэтому не нужно ничего компилировать. Но это только мое личное мнение ...
mliebelt
1
@mliebelt - CI распространяется не только на проверку компиляции. Вы можете запустить модульные / интеграционные тесты (даже с другими зависимыми проектами).
Апурв Хурасия

Ответы:

31

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

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

Mnementh
источник
Я собираюсь добавить достойный интерфейс к этому также.
Мартейн Вербург
Да, я бы подвел итог пользовательского интерфейса под простой в использовании.
Мнемент
5
Круиз-контроль - это было тяжело начинать ... Хадсону было так легко встать и бежать. Плагин Chuck Norris ( wiki.hudson-ci.org/display/HUDSON/ChuckNorris+Plugin ) является обязательным.
Сэм Долан
Хадсон действительно великолепен. Хотя мне бы хотелось, чтобы в изоляции было лучше. Если у вас много разных команд, работающих над слабо связанными проектами, вероятность того, что вы наступите друг другу на ноги, довольно высока.
Грег Готье
Этот программист все еще не может настроить Hudson для работы в Windows :(
Mchl
16

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

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

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

Адам Лир
источник
Я собираюсь попробовать TC дома. У нас не было ничего, кроме проблем с cruisecontrol.net.
Никто не
8

Лично я когда-либо использовал только 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

Берин Лорич
источник
Скомпилированное / интерпретированное различие не такое черно-белое. Например, Perl имеет фазу компиляции, которая запускается при запуске (и может быть вызвана отдельно с опцией «-c») для проверки любых синтаксических ошибок.
Эндрю Медико
Это правда. Ruby 1.9 и Python также имеют фазы компиляции. Класс проблемы «Ошибка компиляции» применяется к любому языку, который предупредит вас, если ссылочный класс / переменная / метод не существует во время компиляции. Это определенно относится к любому статически типизированному языку. YMMV на динамических, но строго типизированных языках (таких как Ruby и Python).
Берин Лорич
«как только вы их настроите, вам мало что нужно будет сделать для его обслуживания» - разве это не так для всех серверов непрерывной интеграции?
Брайан Оукли
5

Team Foundation Server

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

Райан Хейс
источник
Под «другими продуктами» вы подразумеваете «продукты Microsoft». Я не критикую вас, но MS структурировала свой технический стек таким образом, чтобы для интеграции с продуктами MS вам требовались другие продукты MS, или много терпения и / или настойчивости.
GKelly
1
Полная чепуха. У них есть API и SDK для почти всего, что они делают, даже для Kinect, но программисты не из MS не знают, потому что они закрывают уши, как только слышат Micros (ссылка на TFS SDK) msdn.microsoft.com/ ru-ru / library / bb130146 (v = VS.80) .aspx
Люк Пуплет
2

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

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

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

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

azheglov
источник
1

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

ebneter
источник
1

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


источник
1

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

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

Стив
источник
1

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

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

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

бретт роджерс
источник
0

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

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

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

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


источник
0

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

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

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

Сэл
источник