Введення
Складно уявити сучасну розробку без Continuous Integration. Багато компаній випускають по кілька релізів на день і проганяють тисячі тестів. З часів Jenkins і Travis CI на ринку з'явилося багато найрізноманітніших інструментів. Більшість з них працюють за моделлю SaaS - ви платите фіксовану плату за використання сервісу, або за кількість користувачів.
Але використання hosted платформ не завжди можливе, наприклад, якщо не можна передавати код програми, або не хочеться залежати від зовнішніх сервісів. У такому випадку виручають системи, які можна встановити на своїх серверах (self-hosted). Бонусом ви маєте повний контроль над ресурсами і можете масштабувати їх згідно з вашими потребами використовуючи, наприклад, amazon ec2.
У цій статті представлено особистий досвід використання декількох opensource self-hosted continuous integration систем. Якщо ви використовували інші системи, розкажіть про це в коментарях.
Основні поняття
Основою будь-якого CI є білд (build) - одиничне складання вашого проекту. Білд може збиратися за різними тригерами - перейшов у репозитарій, pull-request, за розкладом. Білд складається з набору завдань (jobs). Завдання можуть виконуватися як послідовно, так і паралельно. Набір завдань задається перерахуванням всіх завдань або матрицею білда (build matrix) - характеристиками, за якими відбувається поділ. Наприклад, зазначенням версій мови програмування та змінних середовища - для кожної версії мови і кожного значення змінної буде створене своє завдання.
У деяких ci системах також є конвеєр завдань (pipeline) - завдання об'єднуються в групи (stage), всі завдання в поточній групі виконуються паралельно, наступна група виконується тільки якщо попередня група завершилася успішно. Наприклад, конвеєр test - deploy: якщо всі завдання в test завершилися успішно, то можна запускати завдання з групи deploy.
Для ефективної роботи ci важлива наявність кешу - даних, які використовуються для прискорення збірки. Це можуть бути apt-пакети, кеш npm, composer. Без кешу при запуску кожного завдання потрібно буде заново скачувати і встановлювати всі залежності, що може зайняти часу більше, ніж сам прогін тестів. Чим ближче розташований кеш до серверів, на яких виконуються завдання, тим краще, наприклад, якщо ви використовуєте amazon ec2, то хорошим варіантом буде зберігати кеш в amazon s3.
При виконанні білда можуть генеруватися артефакти - результати складання, звіти про чистоту коду, логи. CI-система, що дозволяє переглядати і скачувати ці артефакти, істотно полегшує життя.
Якщо у вас великий проект з великою кількістю одночасно запущених завдань, то вам не обійтися без масштабування. Масштабування є ручним і автоматичним. При ручному масштабуванні ви самі запускаєте і зупиняєте runner-и на вільних серверах. У разі автоматичного масштабування система сама вирішує, чи потрібно створювати нові віртуальні машини і в якій кількості. Різні ci-системи підтримують різних провайдерів - зазвичай це amazon, google compute, digital ocean тощо.
Важливим є те, як система запускає команди, зазначені в конфігурації білда (executors). Є кілька способів: безпосереднє виконання (на хості, де запущений runner), виконання у віртуальній машині, в docker-контейнері, через ssh. У кожного способу є особливості, які потрібно враховувати при виборі ci-системи, наприклад, при запуску завдання в docker-контейнері відсутня сесія і термінал, через що деякі речі не вийде протестувати. А при виконанні на хості не забувати про очищення ресурсів після закінчення виконання - видалення даних з бд, docker-образів тощо.
Нарешті, є параметри, які не критично важливі, але роблять роботу з ci приємніше. Виведення логу - чи працює він в realtime режимі, чи з якимось інтервалом? Чи можна перервати білд у разі проблем? Чи можна подивитися конфігурацію білда і завдання?
Drone
Drone - система безперервної інтеграції, заснована на docker-контейнерах. Написана мовою Go. Поточна версія - 0.4, версія 0.5 знаходиться в беті. В огляді розглядається версія 0.5.
Drone вміє працювати з великою кількістю git-репозиторіїв - GitHub, Bitbucket, Bitbucket Server, GitLab, Gogs. Конфігурація білдів налаштовується у файлі .drone.yml в корені репозитарію.
Білд складається з декількох кроків, кожен крок виконується паралельно в окремому docker-контейнері. Матриця білда задається за рахунок змінних оточення. Можливо використання сервіс-контейнерів - наприклад, якщо ви тестуєте веб-додаток, який працює з базою даних, то потрібно задати docker-образ БД в секції services, і вона автоматично буде доступна з build-контейнера. Можна використовувати будь- які образи docker.
Drone складається з drone server і drone agent. Drone server виконує роль координатора, а один або кілька drone agent запускають білди. Масштабування здійснюється за рахунок запуску додаткових drone agent-ів. Можливості використовувати хмарні ресурси для автозапуску агентів немає. Вбудованої підтримки кешу не передбачено (є сторонні плагіни для завантаження і збереження кешу на s3 сховища).
Команди, зазначені в білді, виконуються безпосередньо в docker-контейнері інтерпретатором sh, що створює проблеми, якщо потрібно виконувати складні команди з умовною логікою.
Gitlab CI
Gitlab CI є частиною проекту Gitlab - self-hosted аналога Github. Gitlab написаний на ruby, а gitlab runner - на Go. Поточна версія gitlab - 8.15, gitlab runner - 1.9.
Оскільки Gitlab CI інтегровано з gitlab, він використовує тільки gitlab як сховище. Можна дзеркалювати сторонні репозиторії на gitlab, але на мій погляд, це не дуже зручно. Білд організований за принципом конвеєра. Можна налаштовувати тип запуску завдань - автоматично або вручну з веб-інтерфейсу.
Gitlab CI складається з веб-інтерфейсу (координатора) і runner-ів. Координатор розподіляє завдання по runner-ам, які їх виконують. Є великий вибір executors - shell, docker, docker-ssh, ssh, virtualbox, kubernetes. Лог білда не real-time - веб-інтерфейс періодично опитує сервер, якщо з'явилася нова частина лога, то вона додається в кінець.
Є вбудована підтримка кешу, в якості сховища може використовуватися будь-яке s3-сумісне сховище. Є артефакти - можна переглядати окремі файли і скачувати артефакт цілком з веб-інтерфейсу.
Роботу з хмарними ресурсами організовано за допомогою docker mashine. При надходженні запиту на новий білд, якщо немає вільної машини, docker mashine створить нову машину і запустить білд на ній. При цьому образи, необхідні для білда, доведеться завантажити заново, тому gitlab рекомендує підняти окремий docker registry, який був би в тій же мережі, що і провайдер docker mashine.
SimpleCI
Sim^ CI - система безперервної інтеграції, яка була написана для максимально ефективного використання ресурсів. Frontend написаний на php (Symfony3, es6), backend - на java. Поточна версія - 0.6, ведеться активна розробка.
Sim^ CI підтримує github і gitlab сховища. Білд, також, як і в gitlab, організований за принципом конвеєра. Якщо всі завдання в рамках однієї стадії завершилися успішно, то запускається наступна стадія.
Підтримується робота з кешем. Кеш заливається в сховище тільки, якщо в рамках завдання кеш-файли змінилися. Реалізовано роботу з двома типами сховищ - s3-сумісним і google storage.
Білд виконується шляхом запуску docker-контейнерів, підключення до build-контейнера за ssh і запуску build-скрипту. Лог білда відображається в реальному часі (за допомогою websockets і centrifugo).
Є можливість автомасштабування шляхом використання ресурсів хмарних провайдерів (поки тільки google compute engine). При налаштуванні масштабування потрібно вказати snapshot, який буде використовуватися при створенні віртуальної машини. Це дозволяє створити snapshot з необхідними docker-образами, щоб не завантажувати з кожен раз при створенні нової машини. Підтримки артефактів поки немає.
Ув'язнення
В огляді представлено кілька self-hosted open source систем безперервної інтеграції. Крім розглянутих, також є багато hosted, комерційних і відкритих систем. Вибираючи з усього різноманіття CI-систем, звертайте увагу на те, що потрібно вам, і тести скажуть вам спасибі.
Посилання
- Drone
- Gitlab CI
- SimpleCI
- Jenkins
- awersome ci - список ci систем, засобів для тестування та деплою
