Про принципи CI на пальцях
Пояснюється найпростішим чином, що таке неперервна інтеграція. Розглядаються основні принципи практики неперервної інтеграції у командах розробників.
Збережено в:
| Дата: | 2016 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
Інститут кібернетики ім. В.М. Глушкова НАН України
2016
|
| Назва видання: | Компьютерная математика |
| Теми: | |
| Онлайн доступ: | http://dspace.nbuv.gov.ua/handle/123456789/168419 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Про принципи CI на пальцях / А.В. Когут // Компьютерная математика. — 2016. — № 2. — С. 75-79. — Бібліогр.: 3 назв. — укр. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| id |
irk-123456789-168419 |
|---|---|
| record_format |
dspace |
| spelling |
irk-123456789-1684192020-05-02T01:28:51Z Про принципи CI на пальцях Когут, А.В. Инструментальные средства информационных технологий Пояснюється найпростішим чином, що таке неперервна інтеграція. Розглядаються основні принципи практики неперервної інтеграції у командах розробників. Объясняется самым простым образом, что такое непрерывная интеграция. Рассматриваются основные принципы практики непрерывной интеграции в командах разработчиков. The definition and usage of continuous integration are considered in a hand-waving terms. The main principles of continuous integration in the teams of developers are considered. 2016 Article Про принципи CI на пальцях / А.В. Когут // Компьютерная математика. — 2016. — № 2. — С. 75-79. — Бібліогр.: 3 назв. — укр. 2616-938Х http://dspace.nbuv.gov.ua/handle/123456789/168419 681.3 uk Компьютерная математика Інститут кібернетики ім. В.М. Глушкова НАН України |
| institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| collection |
DSpace DC |
| language |
Ukrainian |
| topic |
Инструментальные средства информационных технологий Инструментальные средства информационных технологий |
| spellingShingle |
Инструментальные средства информационных технологий Инструментальные средства информационных технологий Когут, А.В. Про принципи CI на пальцях Компьютерная математика |
| description |
Пояснюється найпростішим чином, що таке неперервна інтеграція. Розглядаються основні принципи практики неперервної інтеграції у командах розробників. |
| format |
Article |
| author |
Когут, А.В. |
| author_facet |
Когут, А.В. |
| author_sort |
Когут, А.В. |
| title |
Про принципи CI на пальцях |
| title_short |
Про принципи CI на пальцях |
| title_full |
Про принципи CI на пальцях |
| title_fullStr |
Про принципи CI на пальцях |
| title_full_unstemmed |
Про принципи CI на пальцях |
| title_sort |
про принципи ci на пальцях |
| publisher |
Інститут кібернетики ім. В.М. Глушкова НАН України |
| publishDate |
2016 |
| topic_facet |
Инструментальные средства информационных технологий |
| url |
http://dspace.nbuv.gov.ua/handle/123456789/168419 |
| citation_txt |
Про принципи CI на пальцях / А.В. Когут // Компьютерная математика. — 2016. — № 2. — С. 75-79. — Бібліогр.: 3 назв. — укр. |
| series |
Компьютерная математика |
| work_keys_str_mv |
AT kogutav proprincipicinapalʹcâh |
| first_indexed |
2025-07-15T03:12:20Z |
| last_indexed |
2025-07-15T03:12:20Z |
| _version_ |
1837680968292368384 |
| fulltext |
Компьютерная математика. 2016, № 2 75
Инструментальные
средства
информационных
технологий
Пояснюється найпростішим чи-
ном, що таке неперервна інтегра-
ція. Розглядаються основні прин-
ципи практики неперервної інтег-
рації у командах розробників.
А.В. Когут, 2016
УДК 681.3
А.В. КОГУТ
ПРО ПРИНЦИПИ CI НА ПАЛЬЦЯХ
Вступ. Уявимо, що у нас є кілька програміс-
тів, які працюють над різними модулями
додатку. Розроблений функціонал прекрасно
працює у кожного із програмістів локально.
В кінці ітерації розробники намагаються зму-
сити працювати всі 3 модуля і тут з’являє-
ться багато проблем з інтеграцією. Програмі-
сти швидко намагаються розібратись з про-
блемою і вирішити її. Ну або ж знайти вин-
ного в усіх бідах. При цьому тестувальники
не приймають ніяких мір, щоб почати тесту-
вання системи. Як результат команда тесту-
вальників має нашвидкоруч працювати, щоб
встигнути до призначеного терміну.
Ці обидва рішення можуть виявитись до-
сить важкими для команди. Вирішення про-
блеми насправді лежить на поверхні – про-
водити інтеграцію максимально часто, можна
сказати неперервно. Таким чином ми автома-
тично вирішуємо багато проблем з інтеграці-
єю. Фактично після кожного коміту ми ба-
чимо і можемо починати виправляти помил-
ки, які пов’язані з інтеграцією коду. Це до-
зволяє вирішувати проблеми своєчасно. Крім
цього, у команди тестувальників завжди є
актуальна версія додатку, що дозволяє еко-
номити час. Часто скрипти запускаються
вручну, що також негативно впливає на весь
процес – всю рутину потрібно автоматизува-
ти. Це зекономить час, не дозволить відволі-
катись на запуск скриптів та вирішить про-
блему людського фактора. Всьому цьому да-
но термін – неперервна інтеграція [1 – 3].
Що таке неперервна інтеграція (Conti-
nuous Integration) – це практика розробки
програмного забезпечення, яка полягає у ви-
конанні частих автоматизованих збірок про-
екту для найшвидшого виявлення та вирі-
шення інтеграційних проблем.
А.В. КОГУТ
76 Компьютерная математика. 2016, № 2
Простіше кажучи, система СІ – це деяка програма, яка слідкує за вашим
Source Control, і при появі там змін автоматично підтягує їх, робить білд, прохо-
дить тести і, можливо, дещо ще, в залежності від конфігурацій. У випадку
невдачі вона дає про це знати всім зацікавленим людям, у першу чергу – остан-
ньому розробнику, який робив коміт.
Що це дає? Те, що в будь-який момент часу ми маємо достовірну інформа-
цію про стан вихідних кодів у системі. Якщо останній білд був невдалим, то
брати свіжу версію із системи контролю версій не можна, оскільки вона може
навіть не скомпілюватись. По-друге, дуже просто знайти того, хто все зламав –
зазвичай, це розробник, який робив останній коміт.
Якщо ж на проекті є юніт-тести, то проганяння їх при кожному білді дає
деяку гарантію відсутності регресійних багів (коли в одному місці помилку
виправили, а в іншому місці з’явилась нова).
Крім того, можна включити в білд різноманітні метрики якості коду, напри-
клад, покриття, статичний аналіз, пошук коду, який дублюється, автоматизувати
установку на тестову машину і т. д.
Continuous Integration відноситься до agile-практик. Agile передбачає ітера-
ційний процес, з великою кількістю повторень циклу розробки, тестування
та видачі продукту.
Розглянемо, що таке Continuous Integration більш детально.
Принципи CI. Якщо хоча б один з принципів не виконується, то процес не
можна називати неперервною інтеграцією.
Build однією командою. «Натиснути одну кнопку – і отримати білд
(деплой) додатку». Це означає, що розробник повинен мати можливість отрима-
ти білд свого додатку вводом однієї команди і скрипт виконає всі необхідні дії.
Деякі проекти використовують власні білд-скрипти або ж деякі команди, які
вводять в консольці, щоб отримати білд. Це не є хорошою практикою. Найкраще
мати єдиний, універсальний скрипт для всіх проектів компанії, який має викону-
вати всі процеси необхідні для білда автоматично.
Переваги автоматизованого білда:
покращення якості продукту;
прискорення компіляції;
звести до мінімуму «погані» білди;
виключити (або звести до мінімуму) конфлікти залежностей;
зберігати історію релізів та білдів.
Фактично, перевагами є покращення якості продукту та уникнення ризиків.
Такі скрипти називаються білд-системами. Сьогодні є досить багато таких
систем. Найпопулярнішими – це Ant, Maven, CMake.
ПРО ПРИНЦИПИ СІ НА ПАЛЬЦЯХ
Компьютерная математика. 2016, № 2 77
Автоматизування білдів
Є три типи білдів:
1) локальний (локально на машині розробника перед комітом; впевнитись,
що нема «поганого» коду);
2) інтеграційний (збирається на спеціальній машині; передбачає послідов-
ність потрібних операцій; коли білд готовий, відправляється звіт);
3) релізний (збирається на спеціальній машині; збірка надсилається команді
тестувальників; потрібні артефакти публікуються в репозиторій).
Є чотири типи білд-механізмів:
1) оn demand (Розробник вручну запускає CI білд);
2) scheduled (так звані «нічні білди». Є фіксовані моменти часу, коли пови-
нен бути запущений білд);
3) рolling for Changes (СІ сервер запитує у системи контролю версій, чи були
внесені зміни. Якщо зміни є, то збирається збірка. Частота запитів налаш-
товується);
4) вuild by Event (деяка зовнішня подія запускає білд. Наприклад, коміт в
систему контролю версій).
Існує деяка залежність між типом білда та його механізмом. Локальні білди
запускаються on demand; для інтеграційних застосовний будь-який механізм;
релізні виконуються on demand або ж scheduled.
Відокремлення білд-скрипту від IDE. IDE може залежати від білд-
скрипту, але він не має бути залежним від IDE. Багато IDE мають власні вбудо-
вані білд-механізми і розробники часто їх використовують. Для CI це не є пога-
ною практикою, потрібно лише сконфігурувати окремий білд-скрипт так, щоб
його можна було запустити з IDE. Така практика підтримує повністю ідентич-
ний білд процес на різних машинах розробників та інтеграційних серверах
(запобігає виникненню проблеми «на моїй машині це працює»).
Централізування доступу до проекту. Має бути можливість отримати всю
необхідну інформацію у будь-який час та в будь-якому місці. Неможливо забез-
печити гнучкі білди без того, щоб тримати коди проекту та залежності в окре-
мому репозиторії. Машина білда має працювати як термінал: отримувати всю
необхідну інформацію з системи контролю версій. Дана практика дозволяє кож-
ному білду бути прозорим та незалежним.
Якщо падати, то швидко. Якщо система виконує багато різних перевірок,
то та частина з них, яка найбільш ймовірно, що падатиме, має виконуватись
у першу чергу. Також це стосується і тестів: найбільш критичні тести та ті, які
падають найчастіше, мають виконуватися першими. Ця практика дозволяє
зменшити час білда і, як результат, час на отримання звіту.
Білд для будь-якого середовища. Білд має бути незалежним від платформи
з окремим білд-скриптом. Тобто, де б не стартували білди: на власній локальній
машині, CI сервері чи машині іншого розробника – на виході мають отриматись
ідентичні файли.
А.В. КОГУТ
78 Компьютерная математика. 2016, № 2
Використання окремої інтеграційної машини для білда. Інколи вся
команда використовує машину певного розробника для того, щоб збирати інтег-
раційні білди. Це не є хорошою практикою тому, що
1. Машина розробника не має достатньо ресурсів для цього.
2. Розробник має підтримувати репозиторій (тобто, витрачати час на нероз-
робницьку діяльність).
3. Така машина не може гарантувати правильного середовища.
4. Активність одного розробника впливає на всю команду.
Щоб уникнути таких проблем, потрібно використовувати окремий сервер.
Сьогодні існує багато таких серверів: Jenkins, Bamboo, TeamCity, CruiseControl
та ін. Їх можна розширювати плагінами, вони підримують більшість існуючих
систем контролю версій, мають різні бекап механізми.
Виконання інтеграційних білдів вручну (необов’язково). Іноді такий білд
може бути корисним. Він запускається з CI сервера чи машини розробника. Як-
що з машини розробника, то відбувається додаткова перевірка на те, чи робочий
код. У випадку CI сервера може знадобитись перезавантаження. Для великих
команд цей принцип не дуже добре застосовувати, оскільки кожен ручний крок
змушує команду працювати повільніше.
Виконування швидких білдів. Має бути можливість отримати звіт на-
стільки швидко, наскільки це можливо.
Для того, щоб швидко отримати звіт потрібно:
збільшити потужність машин для інтеграційних білдів;
часто робити коміти;
оптимізувати білд-скрипт;
покращити інфраструктуру;
покращити виконання тестів;
покращити свій код та стиль, уникати складнощів коду.
Білд за стадіями. Для того, щоб пришвидшити час білда, часто є корисним
розділити білд на кілька частин. Як правило, перша частина є найшвидшою.
Вона компілює код та виконує тести та інспекцію коду. Також вона виконує
деплой на сервер.
Звіти після проходження цієї частини показують розробнику чи є його код
припустимим для подальшого інтеграційного тестування. Отже, такий білд реа-
лізує принцип «швидкого білда». Друга частина – це «важке» інтеграційне тес-
тування та релізи. Фактично, проходження всіх типів тестів. Можуть бути й інші
частини. Наприклад, вони можуть збирати релізи, вручну стартувати білди чи
специфічні тести.
Негайне виправлення зламаного білда. Зазвичай, якщо певний коміт ла-
має білд, то вся команда чи кілька людей у паніці намагаються налаштувати сис-
тему на робочий лад. І це правильно, тому що система має негайно бути виправ-
лена і розробники мають працювати зі стабільним робочим білдом. Зазвичай
ПРО ПРИНЦИПИ СІ НА ПАЛЬЦЯХ
Компьютерная математика. 2016, № 2 79
білд падає у тому випадку, якщо розробник був неуважним і закомітив неробо-
чий код або ж несумісний з тією версією, що лежить у спільному репозиторії
(наприклад, два розробники одночасно вирішили залити один і той же файл і, як
результат, отримали конфлікт).
Як казав Кент Бек: «Ніхто не має важливішою задачі, ніж виправлення
самого білда». І це означає, що не існує задачі більш пріоритетної, ніж отриман-
ня стабільного робочого білда.
Висновки. Отже, неперервна інтеграція може принести дуже багато переваг
для організації, що її використовує. Зокрема, можна попрощатись з довгими
та виснажливими інтеграціями, збільшити прозорість виконання завдань та мож-
ливості виправлення помилок, зменшити час для відлагоджування та збільшити
його для розробки нових ідей.
Які б практики не вводили, що б не робили, не існує ніякого способу дати
100 % гарантію того, що розробники не будуть вносити в систему контролю
версій код, який не компілюється чи не збирається. Звичайно, неперервна інтег-
рація не оберігає такої можливості також, проте вона робить більш простим
шлях для виявлення та знешкодження помилок.
Варто зазначити, що процес розробки є індивідуальним для кожної команди.
Наведені в статті практики є лише основою. Команда розробників може орієнту-
ватись на основні принципи та вносити свої доповнення в залежності від ситуа-
цій, з якими їй доводиться зіштовхуватися.
А.В. Когут
О ПРИНЦИПАХ СИ НА ПАЛЬЦАХ
Объясняется самым простым образом, что такое непрерывная интеграция. Рассматриваются
основные принципы практики непрерывной интеграции в командах разработчиков.
A.V. Kohut
ABOUT CI PRINCIPLES IN A HAND-WAVING TERMS
The definition and usage of continuous integration are considered in a hand-waving terms. The main
principles of continuous integration in the teams of developers are considered.
1. http://www.martinfowler.com/articles/continuousIntegration.htmlапко
2. http://habrahabr.ru/post/229873/
3. http://habrahabr.ru/company/icl_services/blog/262173/
Одержано 30.08.2016
Про автора:
Когут Антоніна Володимірівна,
студентка магістратури факультету кібернетики
Київського національного університету імені Тараса Шевченка.
Е-mail: antoshka412@gmail.com
|