Сервер безперервної збірки (cc.net, Хадсон, бамбук тощо)… досвід віддаленої збірки?

В даний час ми використовуємо один раз сервер cc.net для нашого процесу збирання, який будує як .net (за допомогою msbuild & nant), так і java (за допомогою maven і ant).

CC.net контролює контроль над джерелами та запускає віддалену збірку, що працює на окремому сервері. CC.net потім співставляє результати.

Коли ми запускаємо віддалену збірку, зазвичай:

• виконує nunit або junit або подібне, використовуючи глузувані дані
• необов'язково запускає сценарій БД для створення нового екземпляра бази даних або відновлення бази даних з відомого положення.
• працює селен або подібний до тестового інтерфейсу
• запускає emma або ncover для покриття коду
• будує систему для різних середовищ розгортання (випробування, прийняття, виробництво)

У нас може бути одночасно кілька будівель, деякі .net та деякі Java (від різних команд проектів).

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

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

Хадсон (оновлення: у сучасному світі я б використовував Дженкінс, вилку Хадсона.)

Я використовував Хадсон і в Java, і в середовищі корпоративного середовища .NET для проектів із високою видимістю (ви, мабуть, були на деяких сайтах). Хадсон з самого початку є солідним, але найкраща частина полягає в тому, що є багато плагінів, які можна робити майже все, що завгодно. Хадсон дуже настроюється, має велике співтовариство, і його дуже легко налаштувати в кластерному середовищі, якщо вам потрібно відразу кілька збірок. Це мій улюблений сервер CI з усіх тих, що я використовував (CC.NET, Hudson і TFS).

Крім того, ви можете використовувати плагін ChuckNorris, щоб він давав вам великі пальці вгору або вниз.

Ми стикалися з цим питанням деякий час тому і вирішили піти з TeamCity . Ми дивилися лише на Хадсон, CC та TeamCity. Вибір було легко зробити - TeamCity виявився нашим сервером побудови. Зверніть увагу, що я не фахівець у цьому, і це був мій перший досвід із створенням серверів у той час.

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

Круїз-контроль - такий же, як Хадсон, але дещо по-іншому. Абсолютно нічого тут не можна зрозуміти без посібника та безлічі допомоги Google. Я просто продовжив розглянути ТС.

TeamCity - TeamCity відчув себе небом після перших двох. Він є найбільш корисним із цих трьох. Встановіть, перейдіть до панелі адміністратора, налаштуйте проект (покажіть, де знаходиться SVN, вкажіть на створення файлів, вкажіть тести покриття / одиниці тощо) та почніть насолоджуватися. І хоча я не можу сказати, що нічого не переглядав у Google, все-таки 95% процесу налаштування було дуже простим і зрозумілим. Дуже рекомендую цей інструмент. Ідіть і подивіться на це. Це заощадить вам багато нервів і часу :)

Я також повинен зазначити, що TC не є безкоштовним. Хоча у них є безкоштовне видання, яке можна використовувати з комерційними проектами з деякими обмеженнями (max build config 20) - загляньте на сторінку з цінами.

PS Я звучу так, ніби працюю на TC, але насправді це не так :)

Ми використовуємо CC.NET 1.4.

Ми намагаємось модернізувати до 1.6 ... який кошмар.

Його потужний ... але ТІЛЬКИ, якщо ви правильно його використовуєте і розумієте, як все поєднується разом. Що багато просити у всієї команди. У нас є "майстри-будівельники", які мають доступ до сервера і можуть змінювати конфігурації. Незважаючи на це, є багато гуглінгу щодо ccnet, і весь бізнес став величезним безладом.

Мені особисто хочеться перейти до TeamCity.

Я рекомендую вам триматися подалі від ccnet.

Хороше питання. Наразі ми також намагаємось з’ясувати, який інструмент найкраще підходить для нас. Тож я зможу лише розповісти вам невеликий досвід. Але нам було б дуже цікаво, яку систему ІС ви обрали зараз і з яких причин. Тому, будь ласка, повідомте нас про це.

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

Тепер до нашого досвіду:

Для проектів Java ми використовуємо Bamboo, який чудово працює за допомогою JUnit та Emma. І не так багато зусиль для створення нового проекту.

Для проектів .NET ми все ще шукаємо найкраще рішення

• Круїз-контроль: ми не змогли його запустити ще через проблеми з підключенням до нашого сховища

• TFS:

  a) Для виконання першої збірки необхідно кілька кроків налаштування.

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

  c) Щодо посилань, на які посилаються, є також деякі речі, якими можна керувати, якщо ви хочете поділитися власними програмами для багатьох проектів і не хочете обробляти їх під час кожного окремого проекту

  г) Запустити тест NUnit не так просто, як ми думали. Це просто, якщо ви використовуєте тестове виконання, надане Visual Studio, але це не NUnit

  д) Ми ще не намагалися запустити NCover (спочатку спочатку :-))

• Хадсон: Наступний інструмент, який ми спробуємо. Здається, що дійсно хороший і простий плагін для .NET, я повідомляю вам, як це працювало

• Бамбук: Перший прогноз, який ми отримали: "Занадто специфічний для Java". Але, можливо, ми спробуємо плагін .NET все-таки, я повідомляю вас

Сподіваємось, ми можемо продовжити цю дискусію та обмінятися досвідом.

Енді