Як і чому я встановив машину побудови C #? [зачинено]

Я працюю з невеликою командою розвитку (на 4 особи) над проектом C #. Я запропонував створити машину складання, яка буде робити нічні побудови та тести проекту, тому що я розумію, що це гарна річ. Проблема в тому, що у нас тут не дуже багато бюджету, тому я мушу виправдовувати витрати на владні повноваження. Тому я хочу знати:

Оновлення: Дженкінс - найсучасніша версія Хадсона. Усі повинні зараз використовувати Дженкінса. Я поновлюю посилання відповідно.

Хадсон безкоштовний і надзвичайно простий у налаштуванні і легко працюватиме на VM.

Частково зі старого шахтного поста:

Ми використовуємо це

• Розгорнути служби Windows
• Розгорнути веб-сервіси
• Запустіть MSTests та відображайте стільки інформації, скільки будь-які тести на Джуніт
• Слідкуйте за низькими, середніми, високими завданнями
• попередження та помилки тенденціографа

Ось деякі з вбудованих матеріалів .net, які підтримує Хадсон

• MSBuild
• NAnt
• MSTest
• Нуніт
• Сервер Team Team
• fxcop
• stylecop
• попередження компілятора
• завдання коду

Також, не дай Бог, ви використовуєте безпечний візуальний джерело, він також підтримує це . Я рекомендую вам поглянути на статтю Redsolo про створення проектів .net за допомогою Хадсона

Ваші запитання

• Питання : Які інструменти / ліцензії мені знадобляться? Зараз ми використовуємо Visual Studio і Smart Assembly для створення, а Perforce - для контролю джерел. Чи знадобиться мені щось інше, чи є еквівалент завдання cron для запуску автоматизованих сценаріїв?

• Відповідь: Я щойно встановив візуальну студію на свіжій копії ВМ із запуском свіжої, виправленої, інсталяції ОС Windows-сервера. Тож для цього вам потрібні ліцензії. Хадсон встановить себе як сервіс Windows і запуститься на порт 8080, і ви налаштуєте, як часто ви хочете, щоб він перевіряв ваш сховище коду на оновлений код, або ви можете сказати йому, що він збирається в певний час. Все налаштовується через браузер.

• Питання: Що, власне, отримає мене, окрім вказівки на розбиту конструкцію? Чи повинен я створити тестові проекти в цьому рішенні (файл sln), який буде виконуватися цими сценаріями, щоб я міг перевірити конкретні функції? Наразі у нас є два таких тести, тому що ми не мали часу (чи, чесно кажучи, досвіду) зробити хороші одиничні тести.

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

  • перелік усіх комісій з часу останньої робочої збірки
  • робити нотатки цих комітетів
  • список файлів, змінених у комітах
  • вихід консолі з самої збірки, що показує помилку або помилку тесту

• Питання: Яке обладнання мені знадобиться для цього?

  A: ВМ буде достатньо

• Q: Після того, як збірка закінчена і протестована, чи є звичайною практикою розміщувати цю збірку на ftp-сайті або є інший спосіб внутрішнього доступу? Ідея полягає в тому, що ця машина робить збірку, і всі ми йдемо до неї, але можемо робити налагодження, якщо нам доведеться.

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

• Питання: Як часто ми мусимо робити такий тип побудови?

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

• З: Як управляється космосом? Якщо ми робимо нічні нарощування, чи слід тримати навколо всіх старих конструкцій, або починати їх викопувати приблизно через тиждень або близько того?

  Відповідь: Тобі, після того, як я переміщую наші артефакти побудови на тривале зберігання або видаляю їх, але всі дані, які зберігаються у текстових файлах / XML-файлах, які я зберігаю, це дозволяє мені зберігати журнал змін, графіки трендів, і т. д. на сервері, де зайнято мало місця. Крім того, ви можете налаштувати Хадсона лише для збереження артефактів від затяжної кількості # збірок

• З: Чи є ще щось, чого я тут не бачу?

  Відповідь: Ні, йди за Хадсоном прямо зараз, ти не будеш розчарований!

Ми пощастили з наступним комбо:

1. Visual Studio (зокрема, за допомогою інструмента командного рядка MSBuild.exe та передачі файлів нашого рішення. Прибирає необхідність у скриптах msbuild)
2. NAnt (як синтаксис / бібліотека завдань XML краще, ніж MSBuild. Також є варіанти для операцій управління P4 src)
3. CruiseControl.net - вбудована веб-інформаційна панель для моніторингу / запуску збірок.

CCNet має вбудовані сповіщувачі для надсилання електронних листів, коли збірки успішні / не працюють

На обґрунтування: це знімає навантаження розробників, які роблять ручні побудови, і робить чимало, щоб усунути людські помилки з рівняння. Оцінити цей ефект дуже важко, але як тільки ви це зробите, ви ніколи не повернетесь. Першочерговий процес створення та випуску програмного забезпечення, що повторюється. Я впевнений, що ви були там, де вони розробляють програмне забезпечення вручну, і воно виходить у дикій природі, лише щоб ваш хлопець сказав: "На жаль, я, забув, включив цю нову DLL!"

Про обладнання: настільки потужне, як ви можете отримати. Більше енергії / пам'яті = швидше збільшити час. Якщо ти можеш собі це дозволити, ти ніколи не пошкодуєш, що отримаєш чудову машину для складання, незалежно від того, наскільки мала група.

Простір: допомагає мати достатньо місця на жорсткому диску. Ви можете створити свої сценарії NAnt для видалення проміжних файлів кожного разу, коли починається збірка, тому справжньою проблемою є збереження історії журналів та старих інсталяторів додатків. У нас є програмне забезпечення, яке контролює дисковий простір і надсилає сповіщення. Потім очищаємо привід вручну. Зазвичай це потрібно робити кожні 3-4 місяці.

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

На моєму попередньому робочому місці ми використовували TeamCity . Це дуже просто і потужно у використанні. Його можна безкоштовно використовувати з деякими обмеженнями. Існує також підручник з ролі Dime Casts . Причина, по якій ми не використовували CruiseControl.NET, полягає в тому, що у нас було багато невеликих проектів, і налаштовувати кожен на CC.NET досить болісно. Я б дуже рекомендував TeamCity. Підводячи підсумок, якщо ви рухаєтесь до відкритого коду, то CC.NET - це великий тато з трохи вищою кривою навчання. Якщо ваш бюджет дозволяє вам обов'язково перейти з TeamCity або ознайомитись з безкоштовною версією.

Як? Погляньте на блог Carel Lotz .

Чому? Я можу придумати кілька причин:

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

Стаття Мартіна Фаулера про постійну інтеграцію залишається остаточним текстом. Погляньте на це!

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

Проблема інтеграції роботи декількох розробників є основною небезпекою зростання команди. Чим більше команда отримує, тим важче координувати свою роботу і зупиняти їх возитися зі змінами один одного. Єдине хороше рішення - сказати їм «інтегруватися рано і часто», перевіряючи невеликі одиниці роботи (іноді їх називають «розповідями») по мірі їх завершення.

Ви повинні змусити машину побудови відновити КОЖЕН раз, коли заїжджатимуть протягом дня. За допомогою круїз-контролю ви можете отримати значок на панелі завдань, який стає червоним (і навіть розмовляє з вами!), Коли збірка порушена.

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

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

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

• Візуальна студія. MSBuild працює чудово.
• NAnt .
• NantContrib . Це забезпечить додаткові завдання, такі як операції Perforce.
• CruiseControl.net . Це, зрештою, ваша "приладна панель".

Все вищезазначене (крім VS) є відкритим кодом, тому ви не шукаєте додаткових ліцензій.

Як згадував Earwicker, будуйте рано, будуйте часто. Знаючи, що щось зламалося, і ви можете виготовити доставку корисно для лову речей на початку.

NAnt включає також завдання для nunit / nunit2 , так що ви можете фактично автоматизувати тестування свого пристрою. Потім ви можете застосувати таблиці результатів до результатів і за допомогою рамки, наданої CruiseControl.net, мати приємні для читання результати тестування одиниць для друку для кожної збірки.

Це ж стосується завдання ndoc . Підготовка та доступність вашої документації для кожної збірки.

Ви навіть можете використовувати завдання exec для виконання інших команд, наприклад, виробляючи інсталятор Windows за допомогою InstallShield.

Ідея полягає в тому, щоб максимально автоматизувати збірку, тому що люди роблять помилки. Час, витрачений на передній план, економиться на дорозі. Людям не доведеться доглядати за будівництвом, проходячи процес збирання. Визначте всі етапи вашої збірки, створіть сценарії NAnt для кожного завдання та створіть свої сценарії NAnt по черзі, поки ви повністю не автоматизуєте весь свій процес збирання. Потім він також розміщує всі ваші побудови в одному місці, що добре для порівняння. Щось перерва в Build 426, що добре працювало в Build 380? Ну, є результати, готові до тестування - захопіть їх і випробовуйте.

• Ліцензії не потрібні. CruiseControl.net є у вільному доступі і для створення потрібен лише .NET sdk.
• Сервер збирання, навіть без автоматизованих тестових одиниць, все ще забезпечує контрольоване середовище для випуску версій. Більше не "Джон зазвичай працює на своїй машині, але він хворий. Я чомусь не можу будувати свою машину"
• Зараз у мене є одна установка у сеансі віртуального ПК.
• Так. Збірку потрібно скинути десь доступно. Налаштування розробки повинні включати налагодження. Створення версії повинно бути вимкнено.
• Як часто залежить від вас. Якщо налаштовано правильно, ви зможете створити після кожного заїзду дуже невеликі накладні витрати. Це відмінна ідея, якщо у вас є (або плануєте їх наявність) одиничні тести.
• Зберігайте основні етапи та випуски стільки, скільки потрібно. Все інше залежить від того, як часто ви будуєте: постійно? викинути. Щодня? Тримати тиждень варто. Щотижня? Тримайте два місяці.

Чим більший ваш проект, тим більше ви побачите переваг автоматизованої збірної машини.

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

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

Це також може допомогти наблизити QA та Dev. Оскільки ви можете налаштувати функціональні тести для запуску з ним, разом з профілером та будь-яким іншим, що покращує зворотній зв'язок з командою розробників. Це не означає, що функціональні тести проводяться з кожною реєстрацією (може зайняти деякий час), але ви налаштовуєте збірки / тести за допомогою інструментів, загальних для всієї команди. Я автоматизував тести на дим, тому в моєму випадку ми співпрацюємо ще тісніше.

Чому: 10 років тому ми, як розробники програмного забезпечення, аналізували щось до п ятого ступеня, отримували документи (написані людською мовою), "підписувались", і тоді починаємо писати код. Ми будемо проводити тест, строковий тест, і тоді ми потрапляємо на системний тест: перший раз, коли система в цілому буде працювати разом, іноді тиждень чи місяці після того, як ми підписали документи. Лише тоді ми розкриємо всі припущення та непорозуміння, які мали, коли все проаналізували.

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

Як: Щодо того, як, я трохи пізніше блогував про це: [ Натисніть тут ]

Понад 8 повідомлень покроково розповідає про те, як налаштувати сервер Jenkins у середовищі Windows для .NET рішень.