Як користуватися Jenkins. Поради QA-фахівців NIX

Сучасна розробка побудована навколо концепції CI/CD, яку складно реалізувати без такого інструмента, як Jenkins. Фактично він став стандартом для фахівців. Jenkins безкоштовний, працює з будь-якою операційною системою, його легко налаштувати та підтримувати. Вміти користуватися ним мають як розробники та DevOps, так і QA-автоматизатори. Найголовнішим про Jenkins діляться QA-спеціалісти команди NIX.

Але перш ніж розглянути архітектуру та функціонал Jenkins, пропонуємо розібратись із базовою теорією про CI/CD. Тут маємо два поняття: Continuous Integration та Continuous Delivery.

Розробник робить комміт у загальний репозиторій Git, після чого CI-сервер запускає збірку проєкту. Тобто достатньо запулити реквест, отримати апрув і вмержити в майстер-гілку. А сервер безперервної інтеграції зробить усе сам. Якщо тести не пройдуть, CI-сервер повідомить про це. Цей підхід зручний для великих розподілених команд, де розробники працюють у різних часових поясах. Без моделі CI їм довелося б чекати один одного, а так кожен може робити своє завдання і бачити, що відбувається зі збіркою загального проєкту в репозиторії.

CI-сервер відстежує оновлення на майстер-гілці. Після їх виявлення збирає проєкт, створює артефакт у вигляді архіву — WAR або JAR-файлу (залежно від налаштувань) та деплоїть його на Stage- або Prod-сервер. Завдання розробників те саме — мержити чейнджі в основну гілку. Далі все відбудеться автоматично.

Ідея CI/CD Pipeline об’єднує це все в один великий конвеєр. Розробники працюють над кодом та роблять комміти. Далі CI-сервер збирає проєкт і проганяє інтеграційні та юніт-тести. А після рев’ю все вирушає на Stage і Prod. За автоматизацію відповідає Jenkins. Доставка продукту на сервери проходить безперервно та з мінімальними зусиллями з боку розробників. Від них потрібно лише переглядати результати роботи Jenkins та рев’юїти код після фейлів. Такий підхід спрощує роботу команд та прискорює розробку, що цінують і девелопери, і клієнти.

Що таке Jenkins

Jenkins — це сервер, який підтримує концепцію Continuous Integration. Він написаний на Java, але працює з будь-якими мовами. Ви можете писати код хоч на Python, хоч на C# — для Jenkins це неважливо. У будь-якому разі інструмент збере проєкт так, як ви йому скажете і зробить деплой на сервер, який ви прив’язали до Jenkins.

Розглянемо його інтерфейс та основні функції. На ілюстрації нижче зображено всі джоби. Джоба (тобто job) — це елемент Jenkins, в якому відбувається збірка проєкту.

Jenkins як сервер має комп’ютер-майстер і підлеглі комп’ютери (Slave або Node). Перший комп'ютер роздає завдання, а інші — виконують їх. Але в моєму прикладі на комп’ютері знаходяться і майстер, і ноди (в нижній частині екрану). В результаті маємо три комп’ютери, які на старті перебувають в очікуванні роботи.

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

Базові налаштування Jenkins

При запуску у розділі Manage Jenkins ви побачите повідомлення: про нову версію, оновлення плагінів тощо.

Нижче розміщено кнопки конфігурації. Одна з найважливіших — Plugin Manager. Тут зібрані різні плагіни:

Плагіни розширюють функціонал Jenkins. Їх існує тисячі, причому різних: від картинок з Чаком Норрісом до справді важливих фіч. Сам собою сервер порожній, і навіть Git треба налаштовувати через такі розширення. У цьому немає нічого складного: достатньо завантажити потрібний плагін. Припустимо, ваш проєкт на Python, і ви хочете знайти для нього розширення. Вводите ключове слово у пошуку й отримаєте список плагінів:

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

Крім Plugin Manager, на сторінці налаштувань є й інші цікаві блоки. Наприклад, Global Tool Configuration. У цьому розділі зібрані найважливіші налаштування Jenkins. Як вже згадувалось вище, цей сервер написаний на Java. Тому для роботи потрібен Java Development Kit. В останніх версіях Jenkins підключення виконується автоматично: Jenkins сам знаходить на комп’ютері Java-машину. Але якщо щось пішло не так, потрібно зайти до Global Tool Configuration і звернутися до Maven Configuration. Збирання виконується за допомогою Maven.

Також тут є Gradle, якщо вам потрібно додати його:

А ще — пункт Git. У мене стоїть Default, оскільки Jenkins вже знайшов Maven на комп’ютері. Але ви завжди можете вручну прописати шлях, щоб усе працювало стабільно. Jenkins потребує Git для скачування проєкту з репозиторію, а збирача проєктів — для білда.

Налаштовуємо джоби в Jenkins

У цьому прикладі у верхній частині інтерфейсу розміщується її назва (можете її змінити у себе). Сам Jenkins називає джобу як Project. Ви можете додати шматок коду, гілку або весь проєкт. Для Jenkins це не має значення: він виконає завдання та покаже, чи все нормально зібралося:

Нижче наведено всі збірки. Зверніть увагу на color coding. Завдяки червоним та зеленим міткам ви можете швидко оцінити, які збірки пройшли, а які зафейлились. Другий важливий момент — визначення часу запуску білда. Так ви можете відстежувати, коли востаннє збиралася програма.

QA-автоматизатори точно оцінять Build Time Trend. Тут показано час, протягом якого тривало кожне збирання. Це дозволяє побачити проблеми, наприклад, із сервером. Також можна оцінювати середній час збирання, щоб розуміти, коли чекати фідбек від системи та в разі чого готуватися до виправлення помилок. Мої збірки мають 30-40 секунд, бо я взяла для прикладу маленький проєкт. Зазвичай тривалість набагато більша.

Ви можете звернутися до налаштувань конкретної джоби. Функціонал цього меню однаковий для всіх джоб: і нових, і поточних. Тут у Description я написала, що тестую конкретну сторінку. Краще не пишіть щось на кшталт Small Test. Важливо, щоб ваші колеги розуміли з цього опису, що робить конкретна джоба.

У налаштуваннях джоби є пункт Source Code Management. Тут ви вказуєте, що є Git, і проєкт можна взяти за конкретним посиланням. Завдяки цьому Jenkins зрозуміє, звідки клонувати проєкт. Крім URL-адреси можна вказати SSH та додати креди. Це підвищить захист проєкту від небажаних змін.

Важливий пункт для тестувальників-автоматизаторів — Build Triggers. Тут ви вказуєте періодичність збирання проєкту. Наприклад, щодня о 08:00 чи навіть раз на рік. При цьому в інтерфейсі детально розписано, як налаштовувати цей параметр. Дуже зручно, бо не треба вручну запускати тести на UI чи API. Ви можете задати запуск тестів вночі, а вранці побачити результати:

Також у Build Triggers можна вказати точний розклад перевірок Git. Це особливо зручно для великих команд, де багато розробників та автоматизаторів. Для прикладу я задала системі перевіряти наявність апдейтів у Git щохвилини. Якщо Jenkins знаходить зміни та нові комміти, він клонує проєкт і починає збирання. Звичайно, такий розклад не обов’язковий. Для автотестів вистачить запуску раз на добу. Все індивідуально та залежить від проєкту.

У пункті Bild вказуйте, що потрібно робити з вашим білдом:

Можете обрати з готових кроків: наприклад, Execute Windows або Execute shell для Linux. Я прописала mvn clean test. У результаті Jenkins пройде всі етапи: очищення та верифікація коду, компіляція, тести і насамкінець збирання.

Останній пункт у налаштуваннях джоби — Post Build Action. У ньому треба обрати, що Jenkins робитиме після білда. Завершивши збирання, він може надсилати листа з результатами білда. Також є можливість створювати різні звіти:

Як білдити проєкт за допомогою Jenkins

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

Для прикладу можна розкоментувати один із безлічі локаторів, які не використовуються...

Для цього прописуємо uncomment locators, робимо комміт та пушимо до репозиторію...

Згідно з налаштуваннями, Jenkins щохвилини перевіряє зміни в Git, а при виявленні завантажує їх та запускає збирання. Не зважайте на зелену галочку — це лише результат попередніх збірок. Наші «колірні» результати буде видно лише після поточного збирання.

Тим часом в основному меню ви можете побачити, який комп’ютер зайнятий збіркою, а які — вільні для інших завдань:

Ще цікавий нюанс: позначки у стилі погоди. Наприклад, хмара показує, що окремі збірки зафейлилися, але загалом усе гаразд. Якби всі збірки були зелені, тоді б тут «‎світило» сонечко:

У результаті наша збірка виявилася успішною. Але в реальних проєктах так буває рідко. Тому варто розглянути, як відбувається фейл проєкту й як у такому разі поводиться Jenkins. Для цього відправимося до тих же локаторів і закомітімо: t [text () = 'Hello']. Тут точно немає такого локатора:

Закоммітимо, щоб було зрозуміло, який локатор змінився. Після цього натискаємо на Commit and Push. А далі залишається чекати, як на це відреагує збирач проєктів.

За часом проходження тестів можна подивитися, як працює ваш сервер. Наприклад, якщо при API-тестах час збільшується вдвічі, це ознака проблем в системі. А ще після початку збирання можна натиснути на спеціальну кнопку в бічному меню і вибрати Console Output. Це дозволить у режимі реального часу відстежувати, що Jenkins робить з проєктом. А саме — розписує всі свої кроки: зайшов сюди, зайшов туди, почав збирання тощо:

У цьому прикладі можете бачити Running to do list test — це назва класу. Або, скажімо, є вказівка, що Jenkins запустив Chrome Driver. У цьому розділі немає color coding, через що складніше вловити суть процесів одним поглядом. Але загалом усе написано доступно.

Також Jenkins відображає warning та info. Ви можете задати логування, і система пропише логи або виведе помилки залежно від ваших побажань. Якщо Jenkins знаходить помилку, то час прогону тестів помітно збільшується, після чого з’являється такий червоний символ:

Щоб розібратися в причинах проблеми, зверніться до нижньої частини репорту. Зазвичай Jenkins позначає повідомлення про помилку компіляції коду за допомогою індексу at. У наведеному прикладі система прописує: element location, find element тощо. Тобто Jenkins ніби каже: «‎У вас щось не так із локатором, я не зміг до нього звернутися». Більше того — він навіть вказує на метод.

Нижче бачимо підсумок: заранились три тести, впали — два.

При детальному вивченні звіту можна знайти вказівку на конкретний локатор. Хоча це більше залежить від налаштувань логування на вашому проєкті.

В основному меню Jenkins ви побачите відповідну позначку про фейли навпроти останнього білда:

Поради для ефективної роботи з Jenkins

До неї варто звертатися не лише тоді, коли вам щось не вдалося. Найкраще вивчати офіційну документацію відразу після перегляду мануалів на YouTube та установки Jenkins. У документації ви знайдете все: від налаштувань для різних ОС до відео від спеціалістів зі способами конфігурації під їхні проєкти. Інформація подається дуже просто.

Не варто задавати багато тестів на один білд. Це позначиться на тривалості збирання проєкту. Якщо після фейлу ви внесете зміни, закинете їх майстру і запустите тест-сьют на годину, навряд чи це сподобається команді. Людям доведеться чекати, поки ви побачите, де виникла проблема: у тестах чи в програмі. Тому краще робити короткі сьюти — не більше 15-20 хвилин. Або ще варіант — запускати тести паралельно в самому коді. Це помітно прискорить усі процеси та отримання зворотного зв’язку.

У своєму прикладі я показала 12 збірок, і комп’ютер працював із двома джобами. Це нормальні показники: комп’ютер виконує свої завдання швидко. Але якщо уявити великий проєкт, де одна команда має 12 джоб, друга — ще 12, а третя — 10, то збірки займатимуть занадто багато місця. Тому сервер працюватиме не так добре, як міг би. Щоб уникнути цього, задайте спеціальні налаштування. Наприклад, зберігати тільки останні п'ять збірок. Цього цілком достатньо, аби давати адекватну загальну картину про стан програми і тестів.

Шукайте best practices в офіційній документації. Розробники Jenkins описали чимало завдань, з якими ви можете зіткнутися на практиці. Тому фахівці, які працюють із цим інструментом багато років, при появі будь-якої проблеми спершу йдуть читати документацію Jenkins.