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