Тема 5.6 Сервера п про стійної інтеграції (Hudson, CruiseControl)

  ВИЗНАЧЕННЯ. ВСТУП В безперервні інтеграції.

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

    Безперервна інтеграція є одним з основних методів гнучкої розробки.

    CI призначена для гнучкої розробки. Вона організовує розробку за допомогою функціональних користувальницьких легенд (user stories). Цих легенди утворюють окремі групи завдань, спринти (sprints).

    Ідея в тому, щоб не намагатися вирішити кожну проблему заздалегідь, а зосередитися на вже відомі речі. Таким чином, група проектує, збирає і перевіряє те, що напевно забезпечить необхідну функціональність. Це призводить до створення робочого продукту, заснованого на підмножині повних вимог. Потім група переходить до наступного за пріоритетністю набору вимог, і процес повторюється. Звичайно, це дуже спрощений погляд, і існує багато варіантів цього процесу, проте ядро ​ ​ одне: покрокова побудова продукту з поступовим вдосконаленням.

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

1.1   ПРАКТИЧНА ЗАВДАННЯ

Механізми функціонування CI:

· Системи управління версіями.

    Дозволяє організувати зберігання всіх складових проекту (початкові коди програми та баз даних, налаштування середовищі розробки, документація, тестові дані, бібліотеки та компоненти). Виробляє повідомлення CI серверу, про проведені зміни. Створює резервне зберігання даних.

· Сценарій побудови;

◦ Ключовий елемент збірки;

◦ Не залежить від IDE;

◦ Як параметри отримує файл настройок;

◦ Складається з набору цілей виконання (компіляція, інтеграція, запуск тестів, запуск інспекції коду і т. д.)

◦ Сервер безперервної інтеграції:

▪ Збірки;

▪ Кожен тип збірки у вигляді окремого завдання;

▪ Введення журналу вироблених дій;

▪ Повідомлення розробників;

▪ Публікація звітів;

▪ …

▪ Операції копіювання з репозиторію, збірки і тестування всього проекту автоматизовані і легко викликаються з зовнішньої програми.

ОРГАНІЗАЦІЯ

На виділеному сервері організовується служба, до завдань якої входять:

· отримання вихідного коду з репозиторію;

· збірка проекту;

· виконання тестів;

· розгортання готового проекту;

· відправка звітів.

РОБОТА З репозитарій

· Всі дані зберігаються в репозиторії;

· Часті коммітов;

· Локальна збірка перед коммітов;

· Предкоммітная збірка на інтегрованому сервері;

· Припинення роботи з репозиторієм до виправлення помилок;

ЗБІРКА ПО РОЗКЛАДОМ

Локальна збірка може здійснюватися:

· за зовнішнім запитом;

· за розкладом;

· за фактом поновлення сховища та за іншими критеріями.

    У разі збірки за розкладом (daily build - щоденна збірка), вони, як правило, проводяться кожної ночі в автоматичному режимі - «нічні збірки» (щоб до початку робочого дня були готові результати тестування). Для відмінності додатково вводиться система нумерації збірок - зазвичай, кожна збірка нумерується натуральним числом, яке збільшується з кожною новою збіркою. Вихідні тексти та інші вихідні дані при взятті їх з репозиторію (сховища) системи контролю версій позначаються номером збірки. Завдяки цьому, точно така ж збірка може бути точно відтворена в майбутньому - достатньо взяти вихідні дані по потрібній мітці і запустити процес знову. Це дає можливість повторно випускати навіть дуже старі версії програми з невеликими виправленнями.

АВТОМАТИЗАЦІЯ ЗБІРКИ

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

    Звичайно, для цього потрібна автоматизація процесу складання, тому що непрактично доручати людині задачу багаторазового створення збірок - знову і знову протягом усього робочого дня. Більше того, процес складання повинен виконуватися швидко, для чого часто потрібно багатопоточне складання. При багатопотоковій збірці збірка різних компонентів програмного забезпечення виконується паралельно, що прискорює весь процес. Для цього потрібно більше обладнання і складніший сценарій. А чим складніше сценарій, тим корисніше стають інструменти управління складанням.

УПРАВЛІННЯ РОБОТОЮ

    Основна ідея гнучкої розробки полягає в тому, що робота розбивається на невеликі, керовані фрагменти. Це ж основна передумова CI: виправляти помилки рано і часто. Це запобігає їх переростанню в більші проблеми, які важче вирішити.

    Одна з переваг цього методу - можливість випускати діючі версії меншого розміру, зібрані і протестовані багато разів по ходу проекту. Кожен випуск зменшує ризик для проекту, так як група перевіряє архітектуру, вимоги і оцінює терміни випуску. У гнучких методах ще не завершена робота називається чергою завдань ( backlog ). Коли починають розподіляти роботу малими кроками, так званими спринті, робота, відведена спринту, називається чергою завдань спринту ( sprint backlog ). Робота, що залишилася для майбутніх спринтів, називається чергою завдань проекту. У спринт має включатися стільки роботи, щоб її можна було виконати в терміни, відведені для спринту.

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

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

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: