Continuous Integration - Анатолій Охотніков

Continuous Integration
29/10/2011

ITEvent

Continuous Integration

Анатолій Охотніков
Softjourn Inc.

Про що буде йти мова
• Що таке continuous integration (CI)?
• Побудова фічі з CI
• Практики та Переваги
• Впровадження
• Інструменти
• Приклади проектів -
Java, PHP, Android
• Висновки

Що таке continuous integration (CI)
• Continuous Integration
(неперервна інтеграція)
це практика розробки
пз, у якій члени
команди часто
інтегруть свої наробки;
звично кожен інтегрує
принаймі щоденно, що
призводить до багатьох
інтеграцій на день.

Copyright © 2000-2011 Softjourn, Inc. All rights reserved

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

• “Це не може працювати (тут)”
• “Використання цього не дає відчутної різниці”
• “Так, ми використовуємо це – як ви можете без
цього жити?”
●
Термін “Continuous Integration” походить з
процесу розробки у XP, як однієї з основних
12 практик. Звичайно CI не вимагає певного
інструменту, але дуже зручно
використовувати спеціальний сервер.
●
Інтеграція це вид процесу "заплати мені зараз або
потім більше".


Просто зробіть це...

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

Побудова фічі у циклі CI
Слідкуйте
За кодом

Публікуйте Будуйте
Результати Продукт

Виконуйте
Тести


Практики CI
• Утримуйте єдиний • Тримайте побудову
репозиторій вихідного швидкою.
коду. • Тестуйте у
• Автоматизуйте побудову. виробничому клоні.
• Побудова з автоматичним • Останній збудований
тестуванням. код легко доступний
• Кожен зберігає роботу для усіх членів
у основу гілку кожного команди.
дня. • Всі мають бачити що
• Кожне збереження має відбувається.
будувати головну гілку на • Автоматизуйте
інтеграційній машині. впровадження.


Утримуйте єдиний репозиторій вихідного коду
• Проекти розробки ПЗ містять багато файлів, що
мають бути організовані разом для побудови продукту.
• Інструменти для управління цим називають
інстуремнтами управління вихідного коду (Source
Code Management tools – SCM), управління
конфігурацією, системи контролю версій, репозиторії.
• Все що потрібно для побудови має бути там, включно
з: тестовими скриптами, файлами властивостей,
схемою бази даних, скриптами інсталяції, сторонніми
бібліотеками.
• Тримайте використання гілок мінімально необхідним.
• В основному, вам потрібно зберігати все
що потрібно для побудови,
виключаючи результати побудови.


Автоматизуйте побудову
• Автоматизована побудова є звичайною
можливістю автоматизованих систем (Make,
Ant, NAnt, MSBuild, і т.п.).
• Загальною помилкою є не включення всього
необхідного у автоматизовану побудову
(чиста машина має запускатись у роботу
швидко!).
• Інкрементальні побудови,
компонентні побудови, цілі.
• Скрипти! Не залежте сильно від IDE.


Автоматизуйте побудову

• Ford 1913

• T700 2018


Робіть побудову з автоматичним тестуванням
• Гарним шляхом виявлення помилок швидше та
ефективніше є включення автоматичного
тестування у процес побудови проекту.
• CI має слабшу вимогу до коду, що само-
тестується ніж TDD (Test-Driven Development).
• Для само-тестування коду вам потрібен набір
автоматичних тестів, які можуть перевірити
велику частину кодової бази на помилки.
• Схід TDD популяризував сім'ю XUnit.
• Інструменти, що фокусуються на повному тестуванні,
як FIT, Selenium, Sahi, Watir, і т.п.
• Не розраховуйте, що тести виявлять
всі проблеми з кодом.


Піраміда тестування


Кожен зберігає роботу у основну гілку кожного дня
• Інтеграція це в основному комунікація.
• Перед комітом успішна побудова робочої копії.
• Для швидкого вирішення проблем – спочатку їх
треба швидко виявити.
• Факт побудови при оновленні власної робочої копії
означає що ви виявляєте конфлітки побудови і
текстові конфлікти.
• Через те що між комітами лише кілька годин, існує
обмежена кількість місць, де може ховатися
проблема. Ви навіть можете використати diff-
debugging.
• Часті коміти стимулюють розробників ділити свою
роботу у маленьки блоки по декілька годин. Це
допомагає відслідкувати прогрес та надає відчуття
поступу.

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

Тримайте побудову швидкою
• Для більшості проектів XP рекомендація
тримати побудову не довше 10 хвилин цілком
прийнятна.
• Швидкість.


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

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


Тестуйте у клоні виробничого середовища

• Часто використовують штучне середовище
для швидкокого тестування комітів та
вторинне тестування у клоні виробничого
середовиша.

• Використовуйте віртуалізацію.


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


Робіть останній збудований код легко доступним
• Всі хто залучений до проекту мають
легко отримати останній варіант
збудованого коду та запустити його: для
демонстрацій, тестування або щоб
подивитись що змінилося.

• Всім відоме місце де можна отримати
останній збудований продукт. Продукт
має принаймі проходити коміт тести
(бути достатньо стабільним).


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

• Монітори у
системному лотці,
ліхтарі, лампи з
лавою, іграшкові
ракетниці і т.п.

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

• Настінний календар
для команди QA з
червоними та
зеленими наліпками,
що вказують на здорові
та зламані білди.

Автоматизуйте впровадження
● Для CI вам потрібні різні середовища
Розробка Тестування Демо

Другорядне
Виробництво
Тестування

• Автоматизуйте переміщення продукту.
• Передбачте відкат з виробництва.
• Поступове(rolling) впровадження у кластерах.
• Випробувальні версії деяким користувачам.


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

Впровадження
• Автоматизуте побудову. Будуйте всю
систему єдиною командою.
Будуйте при потребі.
• Додайте автоматизоване тестування у
вашу побудову. Визначіть основні
частини. Почніть робити.
• Спробуйте прискорити побудову.
Чарівні 10 хвилин.
• Почніть CI від самого початку проекту.
• Шукайте допомогу.

Інструменти
• Jenkins(Oracle Hudson) – написаний на Java,
ліцензовний під MIT, працює у контейнері
сервлетів, підтримує CVS, Subversion, Mercurial,
Git, StarTeam Clearcase, Ant, NAnt, Maven та
shell скрипти.
• CruiseControl – оснований на Java фреймворк
для процесу неперервної побудови.
• CruiseControl.NET – оснований на .NET
автоматизований сервер інтеграції.
• Apache Continuum – сервер неперервної
інтеграції з підтримкою Apache Maven та
Apache Ant. Підтримує CVS, Subversion,
shell скрипти і т.п.

Інструменти
• Дослідження університету Fontys
(США, ЄС, Австралія) 2009 рік:


Jenkins (Oracle Hudson)
• Легке встановлення
• Легка конфігурація
• Підтримка наборів змін
• Постійні посилання
• Інтеграція з RSS/E-mail/IM
• Після-фактичні мітки
• Звітування JUnit/TestNG
• Розподілені побудови
• “Відбитки” фалів
• Підтримка плагінів

Приклад Java проекту
• Автоматичний моніторинг SCM
• Побудова проекту
• Автоматичне тестування
• Статичний аналіз коду
• Публікація артифактів
• Автоматичне впровадження
• Інструменти: Ant, Maven, JUnit, PMD,
FindBugs


Приклад Java проекту: Job

Приклад Java проекту: Build

Приклад Java проекту: JUnit

Приклад Java проекту: FindBugs

Приклад Java проекту: PMD

Приклад PHP проекту
• Автоматичне впровадження
• Інструменти: Ant, phpUnit, pDepend,
phpMD, phpCPD, phpLOC, phpCS,
phpDOC, phpCB


Приклад PHP проекту: Charts


Приклад Android проекту
• Побудова проекту
• Інструменти: Ant, JUnit (custom XML
logger), PMD, FindBugs, Android SDK,
Android Emulator (headless/Xvfb), ADB


Приклад Android проекту: Job


Висновки
• Continuous Integration стала однією
з основних технік у розробці
програмного забезпечення.
• Багато команд виявили що користь
застосування CI значно переважає
недоліки.
• Ефект від раннього виявлення та
виправлення помилок інтеграції
зберігає час та гроші упродовж
життєвого циклу проекту.

Висновки: плюси та мінуси
• Коли unit тести не спрацьовують або виникає • Потрібен початковий
помилка, розробники можуть повернути код у час на налаштування.
попередній стан без помилок, без потреби витрачати
• Детально
час на пошук помилок. розроблений набір
• Розробники виявляють і виправляють проблеми тестів потрібен для
інтеграції постіно – запобігаючи хаосу останніх отримання переваг
хвилин перед релізом. від автоматичного
• Раннє попередження про зламаний/несумісний код. тестування.
• Раннє попередження про конфліктуючі зміни. • Широко-масштабний
• Миттєве unit тестування усіх хмін. рефакторинг може
• Постійна доступність “поточної” зборки для бути проблематичним
тестування, демонстрації або релізу. через постійно змінну
• Миттєвий зворотній зв'язок з розробниками про кодову базу.
якість, функціонал або системний вплив коду що • Витрати на залізо для
вони пишуть. машин побудови
• Часті збереження коду штовхають розробників можуть бути
створювати модульний та меньш складний код. високими.
• Метрики що генеруються з автоматичного тестування
та CI фокусують розробників на впровадженні
функціонального, якісного коду і допомагають
розвинути момент у команді.

Посилання
● http://en.wikipedia.org/wiki/Continuous_integration
● http://www.martinfowler.com/articles/continuousIntegration.html
● http://www.extremeprogramming.org/rules/integrateoften.html
● http://cruisecontrol.sourceforge.net/overview.html
● http://wiki.hudson-ci.org/display/HUDSON/Use+Hudson
● http://continuum.apache.org/
● http://www.wakaleo.com/books/continuous-integration-with-hudson-the-book
● http://www.developer.com/open/article.php/3803646/The-Best-Continuous-Integ
● http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html
● http://jan.krutisch.de/en/2010/01/13/the-hudson-siren-small-pieces-loosely-joine


Питання та обговорення
“Анатолій Охотніков”
<aokhotnikov@softjourn.com>


Continuous Integration - Анатолій Охотніков

More Related Content

Similar to Continuous Integration - Анатолій Охотніков

Recently uploaded

Continuous Integration - Анатолій Охотніков