П'ять найпоширеніших міфів про CI/CD

Зміст

CI/CD (Continuous Integration/Continuous Deployment) - це важлива методологія розробки програмного забезпечення, яка передбачає безперервну інтеграцію (CI) та безперервну доставку (CD) програмного коду.

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

У цій статті, як експерт з DevOps та співзасновник Gart Solutions, я хочу розвінчати найпоширеніші міфи про CI/CD і зробити світ розробки трошки кращим.

CI/CD тільки для великих проєктів

Можливо, один з найрозповсюдженіших міфів - CI/CD використовується тільки великими корпораціями і складними проєктами. Насправді процеси CI/CD можна легко масштабувати до проєктів будь-якого розміру. Кожна команда повинна працювати через систему контролю версій, від невеликих студентських завдань до великих глобальних продуктів.

Наприклад, навіть на невеликому проєкті, ви можете використовувати CI/CD для автоматизованого тестування вашого коду. Встановіть unit тести, інтеграційні тести та тести безпеки, які автоматично виконуються після кожного внесення змін до репозиторію. Це допомагає виявити помилки на ранніх стадіях розробки.

CI/CD and QA. Deployment, Continuous Integration… | by Danny August  Ramaputra | HappyFresh Fleet Tracker | Medium

CI/CD може допомогти вам валідувати код на відповідність стандартам та правилам безпеки.

CI/CD дорого і складно впроваджувати, простіше робити вручну

Впровадження та налаштування процесів CI/CD може здатися складним і недешевим процесом, оскільки він вимагає значних ресурсів. Інколи вартість зростає через використання платних сервісів та інструментів.

Іноді автоматизація процесу, який займає годину-дві щодня, може зайняти кілька місяців. Чи раціонально витрачати на це час і ресурси, якщо ручні методи здаються простішими та економнішими?

Такі думки часто виникають у розробників, які мають дещо обмежений досвід роботи з інструментами DevOps. Насправді CI/CD пропонує безліч переваг:

  • допомагає зменшити ризики та помилки;

  • пришвидшує випуск релізів;

  • автоматизує рутинні процеси;

  • дозволяючи команді зосередитися на розробці функціонала.

Припустимо, вам потрібно вивести новий продукт на ринок. Ви вирішили зекономити кошти і не використовувати CI/CD. Замість цього, ви вручну робите кожен реліз і встановлюєте його на серверах.

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

З CI/CD помилка буде виявлена на етапі автоматизованих тестів.

І головне, іноді вартість та складність впровадження CI/CD можуть бути значно перебільшені :)

CI/CD збільшує ризик виходу помилок в продакшн

Зустрічав думку, що CI/CD може призвести до більшої кількості помилок в продакшні. Річ у тому, що завдяки CI/CD зміни заливаються в середовище без ручної перевірки.

Там, де в процесах залучена людина, завжди буде присутній «людський фактор» і помилки. Коли частина задач автоматизується (завдяки CI/CD), то кількість помилок навпаки кратно зменшується.

Тобто CI/CD не збільшує ризик помилок, а навпаки, він зменшує його завдяки автоматизації тестування, валідації коду та швидкому відкату в разі проблем.

Хочу зазначити, що CI/CD допомагає автоматизувати тестування, але не повністю замінює ручне тестування.

Щоденні релізи

CI/CD не обов'язково означає, що кожна “green” build деплоїться на продакшин. CI/CD означає, що кожен build завжди готовий до розгортання.

CI/CD обмежує індивідуальну креативність розробників

Перше, що хочеться додати - поганому танцюристу і підлога крива. Цей міф виникає з неправильного розуміння того, як працює CI/CD та як він впливає на розробників. Дехто може вважати, що автоматизація та стандартизація, які впроваджує CI/CD, обмежують творчу свободу розробників та усувають індивідуальність.

Насправді ж CI/CD допомагає автоматизувати рутинні та монотонні завдання, та вивільнити час для творчості.

CI/CD не підходить для legacy-проектів

Існує думка, що CI/CD неможливо впровадити в старі, "legacy" проєкти. Насправді, CI/CD може бути поступово впроваджений навіть в старих проєктах, поступово вдосконалюючи процеси розробки та доставки.

Ось як CI/CD може бути поступово впроваджений в старих проєктах:

Оцінка потреб

Почніть з оцінки потреб вашого legacy-проєкту. Визначте, які частини проєкту можуть бути автоматизовані та в яких місцях CI/CD принесе найбільшу користь.

Поступове впровадження

Плануйте впровадження CI/CD поступово, зосереджуючись на найбільш критичних та стабільних частинах проєкту. У деяких випадках, оновлення технологій або перенесення на сучасні платформи може бути частиною процесу впровадження CI/CD.

Також важливий етап - виправлення застарілих бібліотек та фреймворків.

Постійне вдосконалення

CI/CD - це ітеративний процес. Постійно вдосконалюйте та оптимізуйте ваші процеси CI/CD, враховуючи особливості вашого legacy-проєкту.

Замість висновків

CI/CD допомагає спростити та автоматизувати рутинні операції, зменшуючи ризик людських помилок та покращуючи надійність проекту. Якщо вам потрібна допомога з імплементацією CI/CD, з радістю допоможу або проконсультую.

Поділись своїми ідеями в новій публікації.
Ми чекаємо саме на твій довгочит!
Роман Бурдюжа
Роман Бурдюжа@Roman_Burdiuzha

Cloud Architect

186Прочитань
2Автори
5Читачі
На Друкарні з 7 листопада

Більше від автора

  • Важливість мережевого дизайну для розвитку бізнесу

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

    Теми цього довгочиту:

    Devops
  • Порівняння AWS Activate, хмарної програми Google та Microsoft для стартапів

    Якщо ви запускаєте стартап, то, напевно, замислювалися над тим, де розмістити своє рішення. Важливо розуміти, що додаток складається з рядків коду, які повинні працювати на сервері, надаючи користувачам доступ до нього.

    Теми цього довгочиту:

    Devops

Вам також сподобається

Коментарі (0)

Підтримайте автора першим.
Напишіть коментар!

Вам також сподобається