Чи чули ви про CI/CD, але не зовсім розумієте, що це таке?
В ідеальному світі, завдання інженерів програмного забезпечення полягає у створенні коду, який потім потрапляє в робоче середовище, де кінцеві користувачі можуть ним скористатися. Для досягнення успіху бізнесу, важливо, щоб ці продукти були максимально безпомилковими.
Традиційно, розробники працюють у відгалуженнях (гілках) коду і створюють запити на злиття (pull requests), які потім оновлюють основну гілку новими змінами. Також, прийнятою практикою є написання тестів, щоб переконатися, що нові зміни не створюють проблем. Однак, часто розробники не створюють запит на злиття, поки повністю не завершать роботу над функцією. Що відбувається потім?
- Вони витрачають багато часу на синхронізацію своєї кодової бази зі змінами, що відбулися в основній гілці, поки вони працювали.
- Це призводить до численних конфліктів злиття, які потрібно вирішувати.
- Існує ризик того, що вони можуть зламати основну гілку, що вплине на інших розробників до того, як проблему буде виявлено та вирішено.
Якщо ви коли-небудь опинялися в такій ситуації, то знаєте, наскільки це може бути неприємно і неефективно.
Яке ж рішення?
Безперервна інтеграція
Щоб уникнути вищезазначених проблем, команди розробників можуть використовувати практику, яка називається безперервною інтеграцією. Як випливає з назви, вона передбачає регулярне об’єднання змін коду, внесених різними розробниками, у спільний репозиторій. Код, який потрібно інтегрувати, має пройти автоматизовану перевірку, щоб упевнитися, що він не порушує роботу застосунку. Лише після успішного проходження тестів, зміни інтегруються.
Розглянемо сценарій з командою з 10 розробників. Кожен з них створює локальну гілку для реалізації певних функцій. Замість того, щоб чекати повного завершення роботи над функцією, вони надсилають запити на злиття після кожної невеликої зміни. Наприклад, припустимо розробник працює над функцією управління завданнями в додатку і створив новий модальний елемент. Він відразу ж створює запит на злиття для цієї зміни, не чекаючи завершення всієї функціональності.
Перед тим, як ця зміна буде об’єднана з основним кодом, необхідно виконати ряд тестів.
Команди розробників використовують інструменти, такі як Travis CI, для автоматизації цих процесів. Тести запускаються автоматично після надсилання запиту на злиття в цільову гілку.
Результати тестів стають доступними розробнику, який зробив запит на злиття. Це дозволяє швидко внести необхідні зміни. Основні переваги такої інтеграції коду:
- Команда швидко дізнається про будь-які проблеми, що виникли в процесі збірки або тестування, що знижує ризик виходу помилки у виробництво.
- Автоматизація процесу дозволяє команді зосередитися на продуктивності.
Важливо пам’ятати, що дана практика заохочує часті відправлення коду до головної гілки. Щоб це було ефективним, інші члени команди повинні регулярно оновлювати свій локальний репозиторій.
Види тестів
Існує багато видів тестів, які можна включити в процес інтеграції. Ось деякі з них:
- Інтеграційне тестування – перевіряє взаємодію різних частин програмного забезпечення як єдиної групи.
- Модульне тестування – тестує окремі блоки коду, такі як функції або методи.
- Тестування інтерфейсу користувача – перевіряє, як програмне забезпечення працює з точки зору кінцевого користувача.
- Приймальне тестування – перевіряє, чи відповідає програмне забезпечення вимогам бізнесу.
Не потрібно тестувати все одразу, оскільки деякі з цих тестів можуть бути вже розглянуті під час написання коду розробниками.
Інструменти безперервної інтеграції
Ось кілька інструментів, які ви можете почати використовувати для своїх проєктів:
- Travis CI – популярний інструмент у світі відкритого коду, що дозволяє швидко і легко тестувати код.
- Circle CI – забезпечує гнучкість та контроль для автоматизації конвеєра від управління до розгортання.
- Jenkins – пропонує безліч плагінів для підтримки створення, розгортання та автоматизації будь-якого проєкту.
Якщо ви новачок у Jenkins, можете ознайомитись із цим курсом Udemy для вивчення CI з Java та .NET.
Безперервне розгортання
Яка користь від створеної функції, якщо вона тижнями або місяцями залишається у репозиторії до моменту розгортання? Команди розробників, окрім інтеграції невеликих змін в основну гілку, повинні також швидко переносити ці зміни у виробниче середовище.
Метою безперервного розгортання є якнайшвидша доставка змін до користувачів після того, як вони були інтегровані в основну гілку.
Як і у випадку безперервної інтеграції, безперервне розгортання також включає автоматизовані тести і перевірки. Розгортання відбувається лише після їх успішного проходження.
Для ефективного використання безперервного розгортання, команда має забезпечити:
- Автоматизоване тестування – код, що підлягає розгортанню, має відповідати стандартам, встановленим командою. Якщо тест провалено, зміна не повинна інтегруватись.
- Можливість відкоту – навіть з автоматичними тестами, деякі помилки можуть потрапити у виробництво. Команда повинна мати можливість скасувати зміни та повернути систему до попереднього робочого стану.
- Системи моніторингу – важливі для відстеження змін, що відбуваються у виробничому середовищі. Це дозволяє команді відстежувати помилки, з якими стикаються користувачі.
Інструменти, що використовуються для безперервної інтеграції, також можуть забезпечити функціональність для налаштування системи безперервного розгортання. Ви можете знайти багато інформації про це.
Висновок
Продуктивність команди розробників є ключовою для успіху бізнесу. Безперервна інтеграція та безперервне розгортання є важливими методами для досягнення цієї продуктивності.
Безперервна інтеграція дозволяє командам щодня відправляти якомога більше коду. Це полегшує швидке розгортання нових змін для кінцевих користувачів. Впровадження цих практик дає можливість швидко отримувати зворотній зв’язок, що дозволяє бізнесу постійно вдосконалюватись.
Також ви можете дізнатись, як покращити та оптимізувати CI/CD.
Якщо ви розробник, зацікавлений у вивченні CI/CD, ознайомтесь із цим чудовим курсом.
Чи була стаття корисною? Поділіться нею зі своїми друзями!