Що таке Jenkins і як він автоматизує CI/CD
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: Jenkins — сервер автоматизації з відкритим кодом, який допомагає командам розробників збирати, тестувати й розгортати застосунки. Найчастіше він забезпечує процеси CI/CD, тобто регулярну перевірку змін у коді та підготовку наступних версій до випуску. Його можна запустити на власному сервері з системою Linux, але тоді доведеться самостійно дбати про обслуговування, оновлення та безпеку.
Для чого потрібен Jenkins і чим він не є
Jenkins виконує завдання за визначеним сценарієм: отримує код, запускає команди, зберігає результати й повідомляє про успіх або помилку. Завдання може запускатися після зміни в репозиторії, за розкладом або на запит користувача. Репозиторій — це місце зберігання коду разом з історією його змін.
Проте це не система керування розробниками й не заміна інструмента для планування роботи. Jenkins автоматизує технічні дії, а не розподіляє обов’язки чи оцінює команду. Він також не замінює систему контролю версій, наприклад Git, але може працювати з нею.
Типові завдання:
- збирання застосунків, тобто перетворення коду на форму, готову до запуску або розповсюдження;
- виконання тестів і перевірок якості коду;
- підготовка пакетів або образів контейнерів;
- публікація результатів і розгортання застосунків у вибраному середовищі.
Jenkins координує ці дії, але зазвичай виконує їх за допомогою інших інструментів. Сам він не компілює код усіма мовами й не містить тестів конкретного застосунку — він запускає команди, підготовлені командою.
Як Jenkins підтримує CI/CD
CI, тобто безперервна інтеграція, передбачає часте об’єднання змін у коді та автоматичну перевірку того, чи застосунок і далі правильно збирається та проходить тести. Завдяки цьому команда може раніше помітити, що нова зміна порушила роботу наявної функції. Однак результат перевірки не гарантує відсутності помилок: він залежить від охоплення та якості тестів.
CD може означати безперервне доставлення або безперервне розгортання. За безперервного доставлення перевірена версія готова до публікації, але її запуск для користувачів може потребувати схвалення. За безперервного розгортання зміна, що відповідає визначеним умовам, автоматично потрапляє у виробниче середовище. Це середовище, яким користуються реальні користувачі.
Jenkins не нав’язує жодної з цих моделей. Можна налаштувати лише тести, повне розгортання або процес із ручним схваленням перед публікацією. Саме встановлення інструмента не створює процесу CI/CD — потрібно ще визначити кроки, умови успішного виконання та спосіб обробки помилок.
Конвеєр: послідовність виконання роботи
Конвеєр (pipeline) — це опис послідовних етапів автоматизації. У Jenkins його часто записують у файлі Jenkinsfile, який зберігається разом із кодом застосунку. Завдяки цьому зміни в процесі збирання можна переглядати й відстежувати за версіями так само, як зміни в самій програмі.
Уявімо команду, яка розробляє інтернет-магазин. Після надсилання зміни до репозиторію Jenkins може виконати таку процедуру:
- Отримати зазначену версію коду.
- Установити залежності та зібрати застосунок.
- Запустити тести, наприклад перевірку обчислення вартості товарів у кошику.
- Зберегти артефакт, тобто результат збирання, наприклад пакет застосунку.
- Розгорнути цей пакет у тестовому середовищі.
- Дочекатися схвалення уповноваженої особи перед розгортанням у виробничому середовищі.
Якщо тест кошика завершиться помилкою, правильно налаштований конвеєр зупинить подальші етапи. Команда отримає результат виконання та журнали — записи перебігу виконання команд, які допоможуть з’ясувати причину проблеми.
Практичне правило — розгортати той самий артефакт, який раніше пройшов тести. Повторне збирання застосунку перед публікацією може дати інший результат, наприклад через зміну залежностей, що завантажуються.
Власний Jenkins на Linux: що потрібно обслуговувати
Jenkins можна самостійно розмістити на Linux, зокрема як службу або в контейнері. Для цього потрібне сумісне середовище Java. Перед установленням слід перевірити в офіційній документації вимоги вибраної версії Jenkins, підтримувані версії Java та рекомендований спосіб установлення.
У більшій конфігурації Jenkins відокремлює координацію роботи від її виконання. Контролер керує завданнями й конфігурацією, а агенти запускають операції збирання та тестування. Такий розподіл дає змогу добирати середовища виконання для проєктів і зменшувати навантаження на контролер.
Власний хостинг дає контроль над середовищем, але водночас покладає конкретні обов’язки:
- оновлювати Jenkins, систему та плагіни, що розширюють його функції;
- керувати доступом і даними автентифікації, наприклад токенами;
- створювати резервні копії та перевіряти можливість відновлення конфігурації;
- контролювати місце на диску, журнали й використання ресурсів.
Особливої обережності потребує запуск коду від осіб, яким ви не довіряєте. Завдання автоматизації виконує команди, тому не повинно мати зайвого доступу до секретів або виробничої інфраструктури.
Коли варто вибрати Jenkins
Jenkins може бути вдалим вибором, якщо команді потрібні гнучкі процеси, інтеграція з різними інструментами або виконання завдань у власній інфраструктурі. Він також корисний, коли процес випуску застосунку містить нетипові кроки, які складно вмістити в просту схему.
Ця гнучкість має свою ціну: хтось мусить підтримувати конфігурацію та розв’язувати проблеми із сервером і плагінами. Якщо невеликій команді потрібні лише кілька тестів після кожної зміни, сервіс CI/CD, доступний разом із її репозиторієм, може потребувати менше обслуговування.
Перш ніж зробити вибір, почніть з одного процесу: отримання коду, збирання застосунку та запуску тестів. Перевірте, чи можете надійно відтворювати цей процес і хто відповідатиме за його підтримку. Автоматичне розгортання додавайте лише після визначення прав доступу та способу відкату помилкової версії.
Дивіться також: Що таке API?
Читайте також
