Сравнение инструментов непрерывной интеграции: Jenkins, GitLab CI, Buildbot, Drone, и Concourse

Непрерывная интеграция и развертывание – стратегии, которые помогают увеличить скорость разработки и ускорить выпуск хорошо протестированных, готовых к использованию программных продуктов. Непрерывная интеграция позволяет разработчикам тестировать и интегрировать свои изменения в общую кодовую базу для минимизации конфликтов интеграции. Непрерывная доставка устраняет трудности развертывания или выпуска ПО. Непрерывное развертывание – еще один шаг, он развертывает каждую сборку, которая автоматически проходит тестирование.

Программные средства играют большую роль в том, насколько быстро и успешно будут выполняться вышеперечисленные этапы. Программное обеспечение CI/CD может помочь разработчикам автоматически вносить изменения, чтобы сократить время обратной связи.

В этой статье мы сравним самые популярные средства непрерывной интеграции, доставки и развертывания: Jenkins, GitLab CI, Buildbot, Drone и Concourse.

Jenkins

Jenkins является одним из первых серверов непрерывной интеграции с открытым исходным кодом и остается наиболее распространенным на сегодня вариантом. Первоначально входящее в проект Hudson сообщество и кодовая база разделились в ходе конфликтов с Oracle после приобретения ими Sun Microsystems, изначальных разработчиков. Hudson был выпущен в 2005 году, а первый релиз Jenkins – в 2011 году.

Со временем сервер Jenkins превратился в мощную и гибкую систему автоматизации задач, связанных с программным обеспечением. Сам Jenkins используется в основном как фреймворк автоматизации, а большая часть логики реализуется через библиотеки и плагины. Все – от прослушивания вебхуков и просмотра репозиториев до создания среды и поддержки языков – обрабатывается плагинами. Процесс непрерывной интеграции может зависеть от многочисленных сторонних плагинов, что с одной стороны обеспечивает гибкость, с другой – делает среду слишком хрупкой.

Рабочий процесс конвейера Jenkins, который также доступен через плагин, является относительно новой функцией, доступной с 2016 года. Процесс непрерывной интеграции можно декларировать или использовать язык Groovy в файлах репозитория или текстовых полях в веб-интерфейсе Jenkins. Одним из общих замечаний к Jenkins является то, что основанная на плагинах модель конфигурации и возможность определять процессы конвейера или сборки вне репозиториев иногда затрудняет репликацию на другом экземпляре Jenkins.

Система Jenkins написана на Java и выпущена под лицензией MIT.

Читайте также:

GitLab CI

GitLab CI – это инструмент непрерывной интеграции, встроенный в GitLab, платформу для размещения репозиториев и средств разработки git. Первоначально выпущенный как самостоятельный проект, GitLab CI был интегрирован в основное программное обеспечение GitLab с выпуском GitLab 8.0 в сентябре 2015 года.

Процесс НИ в GitLab CI определяется внутри файла в самом репозитории кода с помощью синтаксиса YAML. Затем работа отправляется на машины под названием runners, которые легко настраиваются и могут использовать разные ОС. При настройке runner-серверов вы можете выбрать Docker, shell, VirtualBox или Kubernetes, чтобы определить, как выполняются задачи.

Тесная связь GitLab CI с платформой GitLab имеет определенные последствия для использования программного обеспечения. GitLab CI не подходит разработчикам, которые используют другие платформы для размещения репозиториев. С одной стороны, интегрированная функциональность позволяет пользователям GitLab настраивать среду CI/CD, не устанавливая дополнительных инструментов. Автоматическое тестирование можно запустить с помощью веб-интерфейса, регистрации runner-машин и добавления файла определения конвейера в репозиторий. Тесная взаимосвязь также позволяет вам распределять runner-серверы между вашими проектами, автоматически просматривать текущий статус сборки в репозитории и сохранять артефакты сборки с кодом, который их создал.

GitLab и GitLab CI написаны на Ruby и Go и выпущены под лицензией MIT.

Читайте также: Настройка непрерывной интеграции в GitLab в Ubuntu 16.04

Buildbot

Buildbot – это гибкий фреймворк непрерывной интеграции. Выпущенный в 2003 году в качестве альтернативы проекту Tinderbox от Mozilla, Buildbot разрабатывался в основном как способ автоматизации тестирования сборки на широком спектре платформ.

Buildbot выпускается по лицензии GPL и написан на Python с библиотекой Twisted. Конфигурация Buildbot полностью написана на Python. Это означает, что конфигурация значительно сложнее, чем в других системах, но это дает администраторам возможность для разработки своего идеального рабочего процесса и конвейера. Каждый этап сборки четко разделяется. Buildbot позиционирует себя как структуру с инструментами для создания пользовательских процессов, подобно тому, как веб-фреймворки позволяют создавать пользовательские сайты.

Платформа тестирования сборки Buildbot поддерживает множество различных операционных систем и систем управления версиями. Поскольку Buildbot разработан с учетом тестирования открытого исходого кода, его архитектура позволяет пользователям легко создавать рабочие процессы с индивидуальными платформами и расширять базу проекта. Пользователю нужно только установить несколько пакетов Python, а затем предоставить учетные данные.

Читайте также:

Drone

Drone – это современная платформа непрерывной интеграции с архитектурой на основе контейнеров.

Хотя рассмотренные выше инструменты тоже позволяют запускать сборку с помощью Docker, контейнеры лежат в основе конструкции Drone. Drone написан на Go и был впервые выпущен в 2014 году под лицензией Apache.

Drone работает как средний уровень между Docker и провайдером репозитория. Вместо того, чтобы запускать сервер непрерывной интеграции и подключаться к системе управления версиями, Drone требует информацию учетной записи для загрузки собственных моделей проверки подлинности, пользователя и разрешений. Drone запускается как контейнер. Он поддерживает несколько баз данных и провайдеров репозиториев и имеет встроенную поддержку для настройки сертификатов TLS/SSL.

Drone ищет в репозиториях специальные файлы YAML для определения конвейера. Синтаксис удобочитаемый и простой, чтобы любой, кто использует репозиторий, мог понять процесс непрерывной интеграции. Drone предоставляет плагиновую систему, но она работает не так, как в Jenkins. В Drone плагины являются специальными контейнерами Docker, которые используются для добавления предварительно настроенных задач в обычный рабочий процесс. Это упрощает выполнение общих задач, ведь нет необходимости обрабатывать весь процесс вручную. В этом смысле плагины Drone несколько схожи с командами Unix, которые предназначены для обработки узкопрофильных задач.

Читайте также:

Concourse

Concourse – относительно новая платформа непрерывной интеграции, выпущенная в 2014 году. Подход Concourse к пространству непрерывной интеграции значительно отличается от других инструментов тем, что Concourse пытается абстрагировать все внешние факторы с помощью так называемых ресурсов. Цель этого подхода состоит в повышении доступности сервера интеграции. Это позволяет запускать одни и те же процессы можно на любом сервере Concourse.

Каждая часть процесса непрерывной интеграции состоит из основных примитивов, которые моделируют различные элементы системы. Зависимости каждого этапа определяются явно. Например, для первой задачи может потребоваться последний коммит в репозитории VCS, а на последующих этапах процесса может понадобиться последний коммит, прошедший предыдущие этапы. Этот метод построения конвейеров путем сопоставления точных зависимостей каждого шага приводит к строго определенному поведению.

Concourse не передает данных между задачами и не предоставляет никакого внутреннего способа хранения артефактов сборки. Вся информация, необходимая для следующего этапа, должна быть явно определена и потенциально перенесена во внешнее хранилище. Посредством явных определений Concourse пытается минимизировать количество неизвестных переменных, которые должна учитывать система.

Система Concourse написана на Go и выпускается под лицензией Apache.

Читайте также:

Заключение

Программное обеспечение непрерывной интеграции, доставки и развертывания – это сложные системы автоматизации, предназначенные для обеспечения адаптируемости и повторяемости процессов. Существует множество разных идей и подходов к автоматическому тестированию и сборке. Конечно, ни один инструмент не является универсальным средством для обеспечения потребностей любого проекта, но сегодня разработано достаточно много открытых систем непрерывной интеграции, вам есть из чего выбирать.

Tags: , , , ,

Добавить комментарий