ITEvent: Continuous Integration (ukr)

Continuous Integration29/10/2011

ITEvent

Continuous Integration

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

Про що буде йти мова

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

Java, PHP, Android• Висновки

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

Що таке continuous integration (CI)• Continuous Integration

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


Що таке continuous integration (CI)• Кожна інтеграція

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

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


Що таке continuous integration (CI)• “Це не може працювати (тут)”• “Використання цього не дає відчутної різниці”• “Так, ми використовуємо це – як ви можете без

цього жити?”● Термін “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 з червоними та зеленими наліпками, що вказують на здорові та зламані білди.


Автоматизуйте впровадження

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

Розробка Тестування Демо

Виробництво

● Для CI вам потрібні різні середовища

ДругоряднеТестування


Переваги 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 проекту• Автоматичний моніторинг SCM• Автоматичне тестування• Статичний аналіз коду• Публікація артифактів• Автоматичне впровадження• Інструменти: Ant, phpUnit, pDepend,

phpMD, phpCPD, phpLOC, phpCS, phpDOC, phpCB


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


Приклад Android проекту• Автоматичний моніторинг SCM• Побудова проекту• Автоматичне тестування• Статичний аналіз коду• Публікація артифактів• Інструменти: 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-Integration-Tools.htm

● http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html

● http://jan.krutisch.de/en/2010/01/13/the-hudson-siren-small-pieces-loosely-joined.html

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-Integration-Tools.htm

http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html

http://jan.krutisch.de/en/2010/01/13/the-hudson-siren-small-pieces-loosely-joined.html


Питання та обговорення“Анатолій Охотніков”

<[email protected]>

mailto:[email protected]

Technology

ITEvent: Continuous Integration (ukr)