Які рамки безперервної інтеграції ви використовуєте і чому? [зачинено]

Існує досить багато різних систем безперервної інтеграції (CI), і мені цікаво, який є найпопулярнішим. Які рамки ви використовували на фірмах, де ви працюєте?

Чи є якась причина, що одна рамка CI є популярнішою за іншу - можливо, це пов’язано з тими функціями, які вона пропонує, речами, які інтегруються в неї, чи, можливо, просто маркетингом?

Здається, що безперервна інтеграція використовується більше у світі Java та .net, ніж скажімо, рубін чи пітон. Чому це?

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

Деякі роки тому я користувався пошкодженням контролю . Це також було просто у використанні, але плагінів не було. Але автор вирішив, що він відмовиться від простого рішення і розпочав розробку нової версії, яка складалася з різних серверів, що спілкувались один з одним (що, до біса?). Це не спрацювало добре, і проект відмовився. Я був на пошуках деякий час, але ні круїз-контроль (занадто складний), ні континуум насправді не отримали. До Хадсона, це працювало з першого моменту для мене.

Я використовую TeamCity на роботі та вдома. Він має велику підтримку для різних бігунів збірки і розширюється за допомогою плагінів.

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

Одна з проблем, з якими я зіткнувся з TeamCity, пов’язана зі спробами перевести його на автоматичну версію .NET збірок. Мені довелося налаштувати порівняно складний спосіб вирішення, але як тільки він був на місці, він спрацював як принадність.

Особисто я коли-небудь використовував CruiseControl і CruiseControl.Net. Причина цього пов'язана з економікою. Вони досить стійкі, і як тільки ви їх налаштуєте, вам дійсно потрібно зробити мало для його підтримання. Спільнота користувачів, як правило, дуже корисна, і це може бути розширено до ваших потреб.

Однак, є кілька комерційних пропозицій, про які я знаю (один JetBrains, інший - Atlassian), які пропонують кращий досвід та комерційну підтримку. Я мав намір спробувати ці пропозиції, але справді ще не мав шансів.

Інструменти CI відіграють важливішу роль для компільованих мов, ніж інтерпретовані мови, але це не означає, що інструмент CI витрачається на інтерпретовані мови. Якщо у вас є кілька проектів, які залежать один від одного, і ви хочете, щоб зміни не випадково не порушили його залежності - інструменти CI є безцінними.

Існує три загальні класи проблем, за допомогою яких інструменти CI можуть допомогти вам знайти:

1. Помилки компіляції - якщо підпис класу змінюється таким чином, що розбиває залежність, найкраще знати про це перед немічними годинами результатів.
2. Логічні помилки - якщо поведінка класу змінюється таким чином, що руйнує залежності, краще про це знати рано. Це потрібно перевірити за допомогою якогось автоматизованого тестування, найчастіше одиничного тестування.
3. Тестування на прийняття - якщо у вас є автоматизований набір тестів для запуску готового продукту, краще проводити їх часто.

Інтерпретовані мови не компілюються, тому помилок компіляції не потрібно вловлювати. Однак інші дві проблеми досить поширені, що інструменти CI корисні для проектів у Ruby / Python / Perl / тощо.

Ключовим словом як в логічних помилках, так і в пунктах тестування приймання є "автоматизоване" тестування. Якщо у вас немає набору тестів, якими може запуститися машина, то вам справді не вистачає більших переваг інструментів CI. Автоматизовані набори можна створити з часом, тому ви можете почати з малого.

Редагувати

Дивіться цю приємну діаграму для порівняння функцій великої кількості інструментів CI (про багато з яких я не знав):

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

Сервер Team Foundation

Солідна ІС, тісна інтеграція з Visual Studio та Git як контроль версій . Я бачив більш гнучкі сервери CI, як Хадсон, але тісна інтеграція TFS з іншими продуктами робить досвід настільки безпроблемним, що це просто має сенс для моєї команди.

Я використовую як CruiseControl.NET, так і Хадсон . Деякі мої конструкції - на одній з них, а інші - на іншій.

Чому? Тому що я не інженер-будівельник, а той, хто є будівельним інженером, створив їх таким чином!

У мене немає проблем із налаштуванням моїх конструкцій або скаргами на будь-який продукт. Я повідомляю вам, як тут справи, фактично, і сподіваюся, що ви оціните цю перспективу!

ОНОВЛЕННЯ: Оскільки я опублікував відповідь, Хадсон розщедрився і став Дженкінсом . Наведена вище рекомендація стосується Дженкінса.

Пульс . Це в основному Just Works, що для зайнятого будівельного інженера - велика справа. Вони також мають справді чудову технічну підтримку. Основна причина, якою я це дуже люблю, - це те, що у нас є 250+ проектів, і вони справляються з ними без гикавки; Я не можу сказати те саме для Хадсона.

Наша команда працює в основному в Python, C ++ та Java. Ми використовуємо Buildbot для CI. Ми спочатку почали з цього, тому що він інтегрується з Trac і тому, що він здався простим та простим. Я вважаю, що це вибір системи ІС у світі Python.

Хадсон. Часом це трохи баггі, а деякі цікавіші плагіни насправді не працюють, але з невеликою ручкою це досить зручно.

Напевно, я б замість цього використовував Pulse, але якщо вам потрібно побудувати на декількох платформах, це> $ 5k, що трохи більше.

CruiseControl.NET для постійної інтеграції. Працює досить добре, хоча з дуже великою кількістю проектів збірки, які ми створили в CruiseControl, додаток для настільних лотків CCTray жахливо не реагує навіть на тривалі інтервали оновлення.

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

Ми є магазином Microsoft і теоретично будемо переходити до Microsoft Team Team 2010, коли ми перемістимо наше середовище Team Foundation Server до 2010 року.

Зауважте, що ви повинні мати змогу створити свою програму з командного рядка незалежно від того, працює чи не працює двигун CI.

Це означає, що все, що працює на CI, - це систематизувати виклики для складання, і ви можете вибрати двигун, який найкраще відповідає вашим потребам.

ПЕРСОНАЛЬНО мені подобається Хадсон насамперед за те, що він "відчуває себе" приємно, але я знаю, що якщо все не вдасться, я можу перейти на інший без особливих зусиль. Якщо так, я, мабуть, спочатку досліджую той, який зробив Атласіян, оскільки мені подобається "відчувати" інші програми, які вони створюють.

Зауважте, що взаємозамінність означає, що неважливо, на якій мові вони написані. Я вважаю, що Java була обрана для багатьох двигунів, оскільки багато підтримуваних платформ у поєднанні з багатьма будівельними блоками легко доступні. Потрібен веб-сервер - захопіть один. Потрібно багато паралельних ниток - просто використовуйте їх. Потрібна розтяжність - опустити в банку.

Перш ніж я коли-небудь почув термін "безперервна інтеграція" (Це було ще в 2002 або 2003 роках), я написав сценарій нічного складання, який підключив до відеореєстраторів, схопив чисту копію основного проекту та п'ять менших підпроектів, створив усі потім банки через мурашник потім створили і перерозподілили файл WAR за допомогою другого скрипта мурашки, який використовував завдання мурашки tomcat.

Він працював через cron о 7:00 та надсилав електронну пошту з купою доданих вихідних файлів. Ми використовували його протягом усіх 7 місяців проекту, і він залишився у використанні протягом наступних 20 місяців обслуговування та вдосконалень.

Це працювало чудово, але все ж віддають перевагу Хадсону над сценаріями bash, cron та ant.