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

Вступление

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

Хотя приведенная выше терминология в основном относится к стратегиям и практикам, инструментальные средства программного обеспечения играют большую роль, позволяя организациям достигать этих целей. CI/CD software can help teams advance new changes through a series of stages automatically to reduce the time to feedback and remove friction from the process.

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

Дженкинс

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

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

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

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

GitLab CI

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 and Go и выпущены под лицензией MIT. Вы можете следовать нашему руководству поhow to set up continuous integration pipelines with GitLab CI, чтобы узнать, как настроить эту функцию на вашем сервере GitLab.

Buildbot

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

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

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

Чтобы начать использовать Buildbot для автоматизации процессов сборки, следуйте нашему руководству поhow to install Buildbot on 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-сервер для автоматического тестирования ваших коммитов, следуйте нашему руководствуhow to install and configure Drone on Ubuntu 16.04.

стечение

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

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

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

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

Заключение

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

Related