Сравнение инструментов CI/CD: Jenkins, GitLab CI, Buildbot, Drone и Concourse

Введение

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

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

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

Дженкинс

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

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

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

Jenkins написан на Java и выпущен под лицензией MIT. Следуйте нашему руководству по установке Jenkins в Ubuntu 16.04, чтобы настроить сервер Jenkins для своего проекта.

GitLab CI

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

Процесс CI/CD в GitLab CI определяется в файле в самом репозитории кода с использованием синтаксиса конфигурации YAML. Затем работа направляется на машины, называемые исполнителями, которые легко настроить и которые можно инициализировать во многих различных операционных системах. При настройке исполнителей вы можете выбирать между различными исполнителями, такими как Docker, shell, VirtualBox или Kubernetes, чтобы определить, как выполняются задачи.

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

GitLab и GitLab CI написаны на Ruby и Go и выпущены под лицензией MIT. Вы можете следовать нашему руководству по настройке конвейеров непрерывной интеграции с GitLab CI, чтобы узнать, как настроить эту функцию на вашем сервере GitLab.

Билдбот

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

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

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

Чтобы начать использовать Buildbot для автоматизации процессов сборки, следуйте нашему руководству по установке Buildbot в Ubuntu 16.04.

Дрон

Drone — это современная платформа CI/CD, построенная с архитектурой, ориентированной на контейнеры. В то время как рассмотренные выше инструменты включают возможность запуска сборок с помощью Docker, рабочий процесс на основе контейнеров лежит в основе дизайна Drone. Drone написан на Go и впервые был выпущен в 2014 году под лицензией Apache.

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

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

Чтобы узнать, как настроить сервер Drone для автоматического тестирования ваших коммитов, следуйте нашему руководству по установке и настройке Drone в Ubuntu 16.04.

Зал

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

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

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

Concourse написан на Go и выпущен под лицензией Apache. Если вы хотите узнать, как настроить сервер Concourse для автоматизации процессов непрерывной интеграции, ознакомьтесь с нашим руководством по установке Concourse CI в Ubuntu 16.04.

Заключение

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