CI/CD для JS розробників. Частина перша – теорія

Автор: Інна Іващук, Senior Software Engineer, Engineering, Consultant, GlobalLogic Ukraine

У цій колонці я хочу поговорити про автоматизацію (куди ж без неї). Спробуємо покращити процес розробки та життя JS-розробника та розберемось в чому плюси CI/CD практик, яка різниця між CI vs CD vs CD.  А наступного тижня ми перейдемо до практичної частини та спробуємо запустити Travis CI. Тож, поїхали! 

CI: що це таке та навіщо?

Думаю, ви неодноразово зустрічали термін Continuous integration (або скорочено CI), але що саме мають на увазі під використанням CI?

Сьогодні ми з цим спробуємо розібратись. Перш ніж продовжити знайомство із CI/СD практиками, варто згадати про системи контролю версій, такі як git, svn, mercurial та інші. Швидше за все, більшість із вас є частиною команди та для того, щоб зручно було працювати, контролювати код додатку, який змінюється кожного дня, нам необхідний VCS інструмент, який допоможе без проблем синхронізувати зміни декількох розробників.

Щоб детальніше розібратись із взаємозалежність між системою контролю версій і практикою Continuous integration, глянемо на діаграму вище: у нас є розробник, система контролю версій, і звичайно ж СІ. З даної діаграми випливає, що Continuous integration - це практика, яка дозволяє під час кожної внесеної зміни (new commit), створення pull/merge request, запускати автоматичні перевірки, наприклад тести. У випадку, якщо тести пройшли успішно, запускається білд проєкту і, в результаті, отримуємо артефакт. Під артефактом у нашому випадку можуть виступати, наприклад, docker image, який ми пізніше будемо використовувати, або ж це можуть бути статичні файли, які ми будемо одразу публікувати на Heroku, або на GitHub сторінках, або на surge, або на власних хостингах (VPS). Це, в принципі, неважливо, адже конфігурацію можна підлаштувати під потреби.

А зараз розберемось з етапами CI:

• Підготовка. Ми налаштовуємо середовище, де буде відбуватись запуск наших команд або скриптів. Оскільки, ми зараз говоримо про JS розробку, то у нас буде Node JS і нам потрібно завантажити та встановити всі NPM модулі.
• Перевірка коду. Для цього ми можемо використати ESLint, stylelint, або TSLint. Це залежить від специфіки проєкту, і від мови, яка використовується.
• Тести. Вони допомагають відловлювати помилки у коді набагато швидше і раніше.
• Збірка проєкту (Build), за умови, що всі попередні фази були успішні. Найбільш популярні інструменти для цього, це - webpack, parcel, grunt та Gulp.

Що нам у цьому допоможе? Звісно,

Корисні інструменти

Danger

Корисний інструмент, який можна використати з СІ, і який допоможе зробити автоматичне code review. Перед тим як огляд коду буде виконуватись іншим розробником, можна запускати автоматичну перевірку, до прикладу, з Danger JS.

ReviewDog

Як альтернативу Danger, можна використовувати ReviewDog та зробити перевірку і відразу додавати коментарі для того, щоб базові помилки можна було знайти на фазі коли тільки створений pull request і не залучати інших розробників.

CD: що це та навіщо?

CD має два значення: це Continuous Delivery і Continuous Deployment. Для першого і другого значення це виглядає наступним чином:

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

Різниця між CI, CD та CD

Фаза Continuous Integration актуальна як і для Continuous Delivery, так і для Continuous Deployment. Як ви бачите, кроки абсолютно однакові. Крім того, що у Continuous Delivery є один ручний крок. Якщо ми хочемо зробити реліз та зробити код доступним для кінцевих користувачів, то тут це потрібно робити вручну. А у випадку, якщо у нас повністю сконфігурований та налаштований Continuous Deployment, це все буде відбуватися автоматично. Тобто, код автоматично потрапить із тестового середовища у продакшн, і одразу там можна буде зробити smoke test - тобто швидку перевірку чи все працює так, як очікується.

CI/CD сервіси<

Основні CI/CD інструменти це Jenkins, Travis CI, CircleCI, GitLab CI, GitLab Actions та Bamboo.

А тепер детальніше глянемо на схематичне зображення GitLab CI.

У нас є репозиторій із кодом, де налаштоване відстежування нових merge request або commits, що в свою чергу запускають перевірки, юніт та білд тести, далі вже фаза перевірки коду, тестові середовища (хостинг, хмарні сервіси і тд) та продакшн.

Виглядає це наступним чином:

Якщо мова йде про сучасну веб-розробку, то у нас є система контролю версії, є СІ інструмент, є Docker, оркестратор (kubernetes), і наш додаток знаходиться на одному з хмарних сервісів (Azure, Google Cloud, AWS), то наш CI/CD pipeline буде виглядати ось так:

Як ви бачите, кроки будуть дещо розширені, якщо порівнювати з простою реалізацією. Тобто, під час того як відбувається перевірка та збирання проєкту, ми отримаємо артефакт, який швидше за все буде опублікований на Docker Hub (публічий або внутрішній), а вже потім все буде потрапляти на хмарні сервіси (deployment).

На цьому з теоретичною частиною все. Наступного разу ми поговоримо про плюси кожного рішення, спробуємо швидко сконфігурувати та запустити Travis CI , а наприкінці глянемо на новинку, це - GitHub Actions, які у кінці 2019 стали доступними для всіх.

Читайте практичну частину про CI/CD - за посиланням.

Не перемикайтесь!

Якщо хочете більше корисних матеріалів - завітайте до нашого JS Community!