CruiseControl [.Net] проти TeamCity для постійної інтеграції?

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

Я читав і дізнавався про CruiseControl.NET , що використовується для розробки stackoverflow , та TeamCity з його підтримкою для побудови агентів на різних ОС-платформах та на основі різних мов програмування. Отже, якщо ви маєте певний практичний досвід з обох тих, який з них ви віддаєте перевагу і чому?

В даний час мене найбільше цікавить простота використання та управління інструментом, тим більше, що CC є відкритим кодом, а ТЦ підлягає ліцензуванню в якийсь момент, коли у вас буде багато запущених проектів (адже я це потрібно для невеликої кількості проектів).

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

Я працював над інструментами безперервної інтеграції, починаючи з того, що породив круїз-контроль (версія Java). Я спробував майже всі їх в якийсь момент. Я ніколи не був щасливішим, ніж я з TeamCity. Це дуже просто в налаштуванні і все ще забезпечує велику потужність. Сторінка статистики збірки, яка показує часи збірки, кількість одиниць тесту, швидкість проходження тощо, дуже приємна. Домашня сторінка проекту TeamCity також дуже цінна. Для простих .NET-проектів ви можете просто сказати TeamCity, де знаходиться рішення, і які збірки мають тести, і це все, що йому потрібно (крім місця розташування контролю джерела). Ми також використали кілька складних сценаріїв MSBuild з ним і зробили ланцюжок побудови. Я також пройшов два оновлення TeamCity, і вони були безболісними.

CruiseControl.NET також добре працює. Налаштування складніше, але він має довшу історію, тому легко знайти рішення в Інтернеті. Оскільки CruiseControl.NET є відкритим кодом, у вас також є можливість додати або змінити все, що завгодно. Я використовував CruiseControl.NET з моменту випуску і написав частину раннього коду для cc.tray (на щастя переписав хтось, хто знав краще).

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

Редагувати: Ми щойно перейшли до TeamCity 5.0 кілька тижнів тому, це було черговим безболісним оновленням. Це дозволить нам скористатися покращеними можливостями покриття коду та підтримкою GIT. Зараз ми також використовуємо функції особистого складання та попередньо перевірені функції фіксації, які існували певний час. Я просто подумав, що мені слід оновити відповідь, щоб вказати, що TeamCity постійно вдосконалюється та все ще простий у використанні.

Я був / я великий фанат CC.NET. Наразі у CruiseControl у нас є 5 проектів, і це чудово працює. Написання конфігураційних файлів вручну може бути досконалим, але це добре.

Але .

Після скріншоту Kona: Постійна інтеграція та краще тестування одиниць (перша 1/3 про TeamCity) я також перевірю TeamCity. Мені подобається інтегрована панель тестової панелі та інтерфейс налаштування.

Я думаю, що всі повинні переглянути це відео, перш ніж вибирати CC.NET або TeamCity.

ps: Я сподіваюся, що в мережі також є цінне відео CC.NET.

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

Зараз я використовую TeamCity для проекту, і я його в цілому задоволений, але багато створених ним графіків не особливо корисні, і налаштувати його складніше, ніж Хадсон.

Однак, TeamCity є потужним, безкоштовним для багатьох застосувань і має одну вбивчу функцію: віддалений запуск. Ви можете "заздалегідь" здійснити реєстрацію прямо з IDEA або Eclipse, запустити одну або кілька конфігурацій збірки на сервері TeamCity і вчинити зміни лише в тому випадку, коли збірка є успішною (наприклад, компіляція та проходження всіх тестів).

З огляду на те, що ви можете запустити і TeamCity, і Хадсон за кілька годин, можливо, варто захопити обидва і запустити їх поруч, а також будь-які інші (наприклад, CruiseControl), про які ви можете придумати. Якщо ви не можете швидко витримати сервер CI, щоб зробити порівняльне порівняння, то принаймні у вас є точка даних для простоти встановлення та / або налаштування.

Я їх обох успішно використовував у різних проектах. З точки зору налаштування та адміністративності Team City набагато простіше впоратися. Вам не доведеться ламати файли .config, як це робиться з CC та налаштуванням - вітер. Оскільки у вас не так багато проектів, я б рекомендував Team City за CC, поки ви не зрозумієте, що Team City коштує $ $.

Я використовував як CC.net, так і TeamCity. Мені доручено налаштувати та встановити TeamCity для моєї організації (5 розробників). Наша організація використовує деякі незвичайні практики та інструменти (принаймні, для організацій нашого розміру), такі як Perforce для управління джерелами та багаторазові агенти побудови, що працюють на неоднорідних операційних системах, що спричинило певні головні болі в налаштуваннях. Однак підтримка електронною поштою була абсолютно першокласною в налаштуванні всього. Я отримав відповіді на свої німі запитання буквально за лічені хвилини.

Інтерфейс інтуїтивний та чуйний, а також функціональний. Товар відчуває себе дуже дорого. Конфігурація проста, а веб-інтерфейс достатньо інтелектуальний, щоб оновити себе без будь-якого перезавантаження агента чи серверних служб або навіть оновлення сторінки.

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

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

Не бажаючи кидати на вас альтернативні інструменти :-)

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

https://hudson.dev.java.net/

Переконайтеся, що система, яку ви визначаєте за масштабами, до кількості проектів, які вам знадобляться для обробки ...

Я використовую CruiseControl.Net, але я б не рекомендував його будувати безліч проектів ... У мене є (можливо, трохи дивна) домовленість, де у мене є багато статичних бібліотек C ++, які я складаю в додатки. Кожна бібліотека залежить від інших бібліотек, і додатки витягують набір libs і складають. Кожен ліб має тестовий набір. Кожен додаток має тестовий набір. Я будую для 5 компіляторів і варіацій (Windows) платформ.

Перше, що я виявив - це те, що тригери проектів CC.Net насправді не зовсім потрібні, і мульти-тригер не добре поєднується з тригерами проектів. Спосіб спрацьовування проекту (вони використовують видалення для підключення до сервера, на якому зберігається проект (навіть якщо це проект, яким керує той самий екземпляр CC.Net), а потім витягнути всі проекти з цього сервера і послідовно шукати список. шукати проект, який вас цікавить ...) означає, що вони не мають масштабів. Як тільки ви перейдете над певною кількістю проектів, ви побачите, що CC.Net приймає більшу частину процесора для вашої версії.

Звичайно, це відкритий код, тому ви можете це виправити ... І, я впевнений, це добре для невеликої кількості не взаємозалежних проектів.

Детальніше про проблеми, які у мене виникли, та деякі патчі для CC.Net дивіться тут http://www.lenholgate.com/archives/cat_ccnet.html

Нещодавно я налаштував cc .net. Це прекрасне додаток, але вимагає трохи терпіння. Ви будете редагувати конфігураційні файли у багато блокнотів :)

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

Я не використовував TeamCity, але почув досить багато рекомендацій, і це виглядає досить.

Я мав досвід налаштування та роботи CruiseControl (версія Java) в Linux під час моєї попередньої компанії. Як і більшість людей пропонує, налаштування це не найголовніше. Вам потрібно зрозуміти його рамки, щоб придумати працездатний / керований конфігурацію. Однак, як тільки ти перейшов цю горбку, я відчуваю, що CruiseControl досить гнучка, що дозволяє робити різні речі, щоб відповідати різним сценаріям.

Крім документації CruiseControl, на її вікі-сторінці також є корисна інформація.

У мене немає прямого досвіду роботи з TeamCity. Хоча його функція перед тестовим фіксуванням виглядає досить цікавою.

Інший інструмент CC, який ви можете надати йому, - це бамбук від Atlassian. Набагато простіше в налаштуванні, а інтерфейс приємніший. Хоча він не такий гнучкий, як те, що пропонує CruiseControl.

Третій варіант, який ви можете розглянути: Круїз Thoughtworks. Він побудований на CruiseControl, але пропонує набагато більше функцій, простішу налаштування тощо тощо. Безкоштовно (або з відкритим кодом).

http://studios.thoughtworks.com/cruise-continuous-integration

Я використовую Teamcity протягом останніх 1 з половиною років і маю великий досвід. Я інтегрував ряд проектів .Net та Java та використовував такі інструменти, як MSBuild, Maven тощо. Мені здалося, що Teamcity досить простий у створенні та роботі. Мені вдалося змусити CI працювати за деякими проектами sql, а це було трохи кошмару, який міг бути гіршим з іншими інструментами CI.
Нещодавно оновлено до Teamcity 8.0.6, що було безболісним. Також Teamcity пропонує API REST, який дуже корисний для деяких сценаріїв. Якщо ви використовуєте powerhell для автоматизації побудови, на GitHub доступні певні сценарії інтеграції Psake / Teamcity