В последнее десятилетие достигнуты значительные успехи в сфере разработки инструментов непрерывной интеграции (Continuous Integration, CI) и непрерывного развёртывания (Continuous Delivery, CD). Развитие технологий интеграции разработки и эксплуатации ПО (Development Operations, DevOps) привело к быстрому росту спроса на CI/CD-инструменты. Существующие решения постоянно улучшаются, стремясь идти в ногу со временем, выходят их новые версии, в мире контроля качества ПО (Quality Assurance, QA) постоянно появляется множество новых продуктов. При таком богатстве выбора подбор подходящего инструментария оказывается нелёгкой задачей.
Среди всех существующих CI/CD инструментов существуют два проекта, на которые, определённо, стоит обратить внимание тому, кто ищет что-то из этой сферы. Речь идёт о Jenkins и об инструменте GitLab CI/CD, который является частью платформы GitLab. У Jenkins имеется более 16000 звёзд на GitHub. Репозиторий GitLab на gitlab.com набрал чуть больше 2000 звёзд. Если сравнить популярность репозиториев, то окажется, что Jenkins набрал в 8 раз больше звёзд, чем платформа, в состав которой входит GitLab CI/CD. Но при выборе CI/CD-инструмента это — далеко не единственный показатель, на который стоит обращать внимание. Есть и масса других, и это объясняет то, что во многих сравнениях Jenkins и GitLab CI/CD оказываются очень близко друг к другу.
Возьмём, например, данные с платформы G2, которая аккумулирует отзывы о самых разных продуктах и оценки, которые ставят им пользователи. Здесь средний рейтинг Jenkins, выведенный на основе 288 отзывов, составляет 4,3 звезды. А о GitLab тут имеется 270 отзывов, средний рейтинг этого инструмента составляет 4,4 звезды. Мы не ошибёмся, заявив, что Jenkins и GitLab CI/CD конкурируют друг с другом на равных условиях. Интересно отметить то, что проект Jenkins появился в 2011 году и с тех времён он является излюбленным инструментом тестировщиков. Но при этом проект GitLab CI/CD, запущенный в 2014 году, занял свои позиции, очень высокие, благодаря предлагаемым этой платформой передовым возможностям.
Если говорить о популярности Jenkins в сравнении с другими аналогичными платформами, то отметим, что мы, опубликовав статью, где сравнивались платформы Travis CI и Jenkins, устроили опрос. В нём поучаствовало 85 пользователей. Респондентам было предложено выбрать CI/CD-инструмент, который нравится им больше всего. 79% выбрали Jenkins, 5% выбрали Travis CI, а 16% указали, что они предпочитают другие инструменты.
Результаты опроса
Среди других CI/CD-инструментов чаще всего упоминался GitLab CI/CD.
Если вы всерьёз занимаетесь DevOps, то вам нужно тщательно подбирать соответствующие инструменты, учитывая особенности проекта, его бюджет и другие требования. Для того чтобы помочь вам сделать правильный выбор, мы собираемся провести анализ Jenkins и GitLab CI/CD. Это, хочется надеяться, поможет вам сделать правильный выбор.
Jenkins — это широко известный, гибкий CI/CD-инструмент, предназначенный для автоматизации множества задач, связанных с программными проектами. Jenkins полностью написан на Java, он выпущен под лицензией MIT. Он обладает мощным набором возможностей, направленных на автоматизацию задач, связанных со сборкой, тестированием, развёртыванием, интеграцией, выпуском программного обеспечения. Этот инструмент можно использовать в различных операционных системах. Среди них — macOS, Windows и множество дистрибутивов Linux, например — OpenSUSE, Ubuntu и Red Hat. Существуют установочные пакеты Jenkins, предназначенные для различных ОС, этот инструмент можно установить в Docker и в любой системе, где есть JRE (Java Runtime Environment).
Разработчики Jenkins создали ещё один проект, Jenkins X, который рассчитан на работу в среде Kubernetes. В Jenkins X интегрированы Helm, сервер Jenkins CI/CD, Kubernetes и другие инструменты, предназначенные для создания CI/CD-конвейеров, соответствующих передовым методам DevOps. Например, здесь используется GitOps.
В копилку достоинств Jenkins можно добавить и тот факт, что его скрипты очень хорошо структурированы, понятны, их легко читать. Команда Jenkins создала около 1000 плагинов, которые направлены на организацию взаимодействия Jenkins с самыми разными технологиями. В скриптах можно пользоваться системами аутентификации, что, например, позволяет подключаться к различным закрытым системам.
В процессе работы конвейера Jenkins можно наблюдать за тем, что происходит на каждом его шаге, за тем, успешно или нет завершились те или иные этапы работы. Наблюдать за всем этим можно, правда, не применяя некий графический интерфейс, а пользуясь возможностями терминала.
Среди широко известных особенностей Jenkins можно отметить простоту настройки, высокий уровень автоматизации различных операций и отличную документацию. Если говорить о решении DevOps-задач, то здесь Jenkins считается весьма надёжным инструментом, используя который, как правило, нет смысла пристально наблюдать за всем процессом обработки проекта. В случае с другими CI/CD-инструментами это не так. Давайте поговорим о некоторых важнейших возможностях Jenkins.
Jenkins может работать на платформах macOS, Windows и Linux. Он может функционировать и в среде Docker, что позволяет организовать единообразное и быстрое выполнение автоматизированных задач. Этот инструмент, кроме того, может выполняться в виде сервлета в контейнерах, поддерживающих Java, в таких, как Apache Tomcat и GlassFish. Установка Jenkins качественно документирована.
Экосистема плагинов Jenkins выглядит гораздо более развитой по сравнению с экосистемами подключаемых модулей других CI/CD-инструментов. В настоящее время существует более 1500 плагинов для Jenkins. Эти плагины направлены на решение широкого спектра задач, с их помощью можно автоматизировать самые разные проекты. Богатство выбора бесплатных подключаемых модулей означает, что у того, кто использует Jenkins, нет острой необходимости в покупке дорогостоящих платных плагинов. Существует возможность интеграции Jenkins с множеством DevOps-инструментов.
Jenkins довольно просто устанавливать и настраивать. При этом и процесс обновления системы тоже устроен очень удобно. Тут, опять же, стоит упомянуть о качестве документации, так как в ней можно найти ответы на самые разные вопросы, связанные с установкой и настройкой Jenkins.
Как уже было сказано, Jenkins — это опенсорсный проект, экосистема которого включает в себя огромное количество плагинов. Вокруг Jenkins сложилось большое сообщество пользователей и разработчиков, помогающих развитию проекта. Сообщество — это один из факторов, который способствует развитию Jenkins.
В ходе работы с Jenkins можно пользоваться REST API, что расширяет возможности системы. API для удалённого доступа к системе представлен в трёх вариантах: XML, JSON с поддержкой JSONP, Python. Вот страница документации, раскрывающая подробности о работе с REST API Jenkins.
Jenkins поддерживает распараллеливание DevOps-задач. Его можно легко интегрировать с соответствующими инструментами и получать уведомления о результатах выполнения задач. Выполнение тестирования кода можно ускорить за счёт организации параллельной сборки проекта с использованием различных виртуальных машин.
Jenkins позволяет организовывать распределённые сборки с использованием нескольких компьютеров. Эта возможность применима в больших проектах и использует схему работы, в соответствии с которой существует один главный сервер Jenkins и несколько подчинённых машин. Подчинённые машины могут использоваться и в ситуациях, когда нужно организовать тестирование проекта в разных средах. Эти возможности выгодно отличают Jenkins от других подобных проектов.
GitLab CI/CD можно назвать одним из самых новых и самых любимых DevOps-инженерами инструментов. Этот бесплатный опенсорсный инструмент встроен в систему контроля версий GitLab. У платформы GitLab есть community-версия, она поддерживает управление репозиториями, средства для отслеживания проблем, организацию код-ревью, механизмы, ориентированные на создание документации. Компании могут устанавливать GitLab локально, связывая эту систему с Active Directory и с LDAP-серверами для организации безопасной авторизации и аутентификации пользователей.
Вот видеоруководство, которое поможет вам узнать о том, как создавать CI/CD-конвейеры с использованием возможностей GitLab CI/CD.
Изначально GitLab CI/CD был выпущен как самостоятельный проект, но в 2015 году этот набор инструментов был интегрирован в GitLab 8.0. Отдельный GitLab CI/CD-сервер может поддерживать работу более чем 25000 пользователей. На основе подобных серверов можно создавать системы, отличающиеся высокой доступностью.
GitLab CI/CD и основной проект GitLab написаны на Ruby и на Go. Они выпущены под лицензией MIT. GitLab CI/CD, помимо обычных возможностей CI/CD-инструментов, поддерживать и дополнительные возможности, связанные, например, с планированием работ.
Интегрировать GitLab CI/CD в проект очень просто. При использовании GitLab CI/CD процесс обработки кода проекта делится на стадии, каждая из которых может состоять из нескольких задач, выполняемых в определённом порядке. Задачи поддаются тонкой настройке.
Задачи могут выполняться параллельно. После настройки последовательности стадий и задач CI/CD-конвейер готов к работе. За ходом его выполнения можно наблюдать, отслеживая состояние задач. В результате пользоваться GitLab CI/CD очень удобно, пожалуй, удобнее, чем другими подобными инструментами.
GitLab CI/CD — это один из самых популярных DevOps-инструментов. Проект отличается качественной документацией, его возможностями легко и удобно пользоваться. Если вы пока не знакомы с GitLab CI/CD, следующий список возможностей этого инструмента даст вам общее представление о том, чего от него можно ожидать. Надо отметить, что многие из этих возможностей имеют отношение к самой платформе GitLab, в которую интегрирован GitLab CI/CD.
GitLab CI/CD — это сравнительно новый инструмент, нашедший широкое применение. GitLab CI/CD постепенно стал чрезвычайно популярным CI/CD-инструментом, используемым для автоматизированного тестирования и развёртывания программного обеспечения. Его просто настраивать. Это, к тому же, бесплатный CI/CD-инструмент, встроенный в платформу GitLab.
Jekyll — это генератор статических сайтов, который можно использовать в рамках системы GitLab Pages для создания сайтов на основе GitLab-репозиториев. Система берёт исходные материалы и генерирует на их основе готовый статический сайт. Управлять внешним видом и возможностями таких сайтов можно, редактируя файл
Благодаря возможности по планированию этапов проектов повышается удобство отслеживания проблем и их групп. Это позволяет управлять организацией работ по проектам, планировать их выполнение на конкретную дату.
Благодаря автоматическому масштабированию раннеров, ответственных за выполнение конкретных задач, можно серьёзно сэкономить на стоимости аренды серверных мощностей. Это очень важно, особенно — если речь идёт о средах, где тестирование проектов выполняется параллельно. Кроме того, это важно для крупных проектов, состоящих из нескольких репозиториев.
Мощные возможности GitLab по отслеживанию проблем привели к тому, что эту платформу используют многие опенсорсные проекты. GitLab CI/CD позволяет выполнять параллельное тестирование различных веток кода. Результаты испытаний удобно анализировать в интерфейсе системы. Это выгодно отличает GitLab CI/CD от Jenkins.
Платформа GitLab поддерживает ограничение доступа к репозиториям. Например, тем, кто совместно работает над проектом в некоем репозитории, можно назначить права, соответствующие их ролям. Это особенно актуально для корпоративных проектов.
Вокруг GitLab сложилось активное сообщество, которое способствует развитию этой платформы и её инструментов, в частности — GitLab CI/CD. Глубокая интеграция GitLab CI/CD и GitLab, кроме прочего, упрощает нахождение ответов на вопросы, возникающие при работе с GitLab CI/CD.
GitLab CI/CD — это система, которая способна работать не только с кодом, размещённым в репозиториях GitLab. Например, код можно хранить в GitHub-репозитории, а CI/CD-конвейер можно организовать на базе GitLab с использованием GitLab CI/CD.
Jenkins и GitLab CI/CD — это очень хорошие инструменты, каждый из которых способен обеспечить нормальную работу CI/CD-конвейера. Но, если их сравнить, окажется, что они, хотя и во многом похожи, кое-чем друг от друга отличаются.
Описав и сравнив Jenkins и GitLab CI/CD, давайте сосредоточимся на различиях этих DevOps-инструментов. Знание об этих различиях позволит понять тех, кто предпочитает один из этих инструментов другому.
Сейчас у вас сложилось некоторое представление о Jenkins и GitLab CI/CD. Теперь, чтобы вы ещё лучше познакомились с этими инструментами, давайте разберём их сильные и слабые стороны. Полагаем, что вы уже приняли решение о том, какой именно инструмент вам нужен. Хочется надеяться, этот раздел позволит вам проверить себя.
И Jenkins, и GitLab CI/CD имеют сильные и слабые стороны. Ответ на вопрос о том, что именно выбрать, зависит от нужд и особенностей конкретного проекта. Каждый из рассмотренных сегодня CI/CD-инструментов отличается определёнными особенностями, хотя созданы эти инструменты для решения одной и той же задачи. При этом Jenkins — это автономный инструмент, а GitLab CI/CD — это часть платформы, предназначенной для совместной работы над кодом.
Выбирая CI/CD-систему стоит, помимо её возможностей, принимать во внимание и те затраты, которые могут быть с ней связаны, и то, с чем именно привыкли работать DevOps-инженеры, поддерживающие проект.
Какими CI/CD-инструментами вы пользуетесь?
Среди всех существующих CI/CD инструментов существуют два проекта, на которые, определённо, стоит обратить внимание тому, кто ищет что-то из этой сферы. Речь идёт о Jenkins и об инструменте GitLab CI/CD, который является частью платформы GitLab. У Jenkins имеется более 16000 звёзд на GitHub. Репозиторий GitLab на gitlab.com набрал чуть больше 2000 звёзд. Если сравнить популярность репозиториев, то окажется, что Jenkins набрал в 8 раз больше звёзд, чем платформа, в состав которой входит GitLab CI/CD. Но при выборе CI/CD-инструмента это — далеко не единственный показатель, на который стоит обращать внимание. Есть и масса других, и это объясняет то, что во многих сравнениях Jenkins и GitLab CI/CD оказываются очень близко друг к другу.
Возьмём, например, данные с платформы G2, которая аккумулирует отзывы о самых разных продуктах и оценки, которые ставят им пользователи. Здесь средний рейтинг Jenkins, выведенный на основе 288 отзывов, составляет 4,3 звезды. А о GitLab тут имеется 270 отзывов, средний рейтинг этого инструмента составляет 4,4 звезды. Мы не ошибёмся, заявив, что Jenkins и GitLab CI/CD конкурируют друг с другом на равных условиях. Интересно отметить то, что проект Jenkins появился в 2011 году и с тех времён он является излюбленным инструментом тестировщиков. Но при этом проект GitLab CI/CD, запущенный в 2014 году, занял свои позиции, очень высокие, благодаря предлагаемым этой платформой передовым возможностям.
Если говорить о популярности Jenkins в сравнении с другими аналогичными платформами, то отметим, что мы, опубликовав статью, где сравнивались платформы Travis CI и Jenkins, устроили опрос. В нём поучаствовало 85 пользователей. Респондентам было предложено выбрать CI/CD-инструмент, который нравится им больше всего. 79% выбрали Jenkins, 5% выбрали Travis CI, а 16% указали, что они предпочитают другие инструменты.
Результаты опроса
Среди других CI/CD-инструментов чаще всего упоминался GitLab CI/CD.
Если вы всерьёз занимаетесь DevOps, то вам нужно тщательно подбирать соответствующие инструменты, учитывая особенности проекта, его бюджет и другие требования. Для того чтобы помочь вам сделать правильный выбор, мы собираемся провести анализ Jenkins и GitLab CI/CD. Это, хочется надеяться, поможет вам сделать правильный выбор.
Знакомство с Jenkins
Jenkins — это широко известный, гибкий CI/CD-инструмент, предназначенный для автоматизации множества задач, связанных с программными проектами. Jenkins полностью написан на Java, он выпущен под лицензией MIT. Он обладает мощным набором возможностей, направленных на автоматизацию задач, связанных со сборкой, тестированием, развёртыванием, интеграцией, выпуском программного обеспечения. Этот инструмент можно использовать в различных операционных системах. Среди них — macOS, Windows и множество дистрибутивов Linux, например — OpenSUSE, Ubuntu и Red Hat. Существуют установочные пакеты Jenkins, предназначенные для различных ОС, этот инструмент можно установить в Docker и в любой системе, где есть JRE (Java Runtime Environment).
Разработчики Jenkins создали ещё один проект, Jenkins X, который рассчитан на работу в среде Kubernetes. В Jenkins X интегрированы Helm, сервер Jenkins CI/CD, Kubernetes и другие инструменты, предназначенные для создания CI/CD-конвейеров, соответствующих передовым методам DevOps. Например, здесь используется GitOps.
В копилку достоинств Jenkins можно добавить и тот факт, что его скрипты очень хорошо структурированы, понятны, их легко читать. Команда Jenkins создала около 1000 плагинов, которые направлены на организацию взаимодействия Jenkins с самыми разными технологиями. В скриптах можно пользоваться системами аутентификации, что, например, позволяет подключаться к различным закрытым системам.
В процессе работы конвейера Jenkins можно наблюдать за тем, что происходит на каждом его шаге, за тем, успешно или нет завершились те или иные этапы работы. Наблюдать за всем этим можно, правда, не применяя некий графический интерфейс, а пользуясь возможностями терминала.
Особенности Jenkins
Среди широко известных особенностей Jenkins можно отметить простоту настройки, высокий уровень автоматизации различных операций и отличную документацию. Если говорить о решении DevOps-задач, то здесь Jenkins считается весьма надёжным инструментом, используя который, как правило, нет смысла пристально наблюдать за всем процессом обработки проекта. В случае с другими CI/CD-инструментами это не так. Давайте поговорим о некоторых важнейших возможностях Jenkins.
?1. Бесплатность, открытый исходный код, поддержка множества платформ
Jenkins может работать на платформах macOS, Windows и Linux. Он может функционировать и в среде Docker, что позволяет организовать единообразное и быстрое выполнение автоматизированных задач. Этот инструмент, кроме того, может выполняться в виде сервлета в контейнерах, поддерживающих Java, в таких, как Apache Tomcat и GlassFish. Установка Jenkins качественно документирована.
?2. Развитая экосистема плагинов
Экосистема плагинов Jenkins выглядит гораздо более развитой по сравнению с экосистемами подключаемых модулей других CI/CD-инструментов. В настоящее время существует более 1500 плагинов для Jenkins. Эти плагины направлены на решение широкого спектра задач, с их помощью можно автоматизировать самые разные проекты. Богатство выбора бесплатных подключаемых модулей означает, что у того, кто использует Jenkins, нет острой необходимости в покупке дорогостоящих платных плагинов. Существует возможность интеграции Jenkins с множеством DevOps-инструментов.
?3. Простая установка и настройка
Jenkins довольно просто устанавливать и настраивать. При этом и процесс обновления системы тоже устроен очень удобно. Тут, опять же, стоит упомянуть о качестве документации, так как в ней можно найти ответы на самые разные вопросы, связанные с установкой и настройкой Jenkins.
?4. Дружелюбное сообщество
Как уже было сказано, Jenkins — это опенсорсный проект, экосистема которого включает в себя огромное количество плагинов. Вокруг Jenkins сложилось большое сообщество пользователей и разработчиков, помогающих развитию проекта. Сообщество — это один из факторов, который способствует развитию Jenkins.
?5. Наличие REST API
В ходе работы с Jenkins можно пользоваться REST API, что расширяет возможности системы. API для удалённого доступа к системе представлен в трёх вариантах: XML, JSON с поддержкой JSONP, Python. Вот страница документации, раскрывающая подробности о работе с REST API Jenkins.
?6. Поддержка параллельного выполнения задач
Jenkins поддерживает распараллеливание DevOps-задач. Его можно легко интегрировать с соответствующими инструментами и получать уведомления о результатах выполнения задач. Выполнение тестирования кода можно ускорить за счёт организации параллельной сборки проекта с использованием различных виртуальных машин.
?7. Поддержка работы в распределённых средах
Jenkins позволяет организовывать распределённые сборки с использованием нескольких компьютеров. Эта возможность применима в больших проектах и использует схему работы, в соответствии с которой существует один главный сервер Jenkins и несколько подчинённых машин. Подчинённые машины могут использоваться и в ситуациях, когда нужно организовать тестирование проекта в разных средах. Эти возможности выгодно отличают Jenkins от других подобных проектов.
Знакомство с GitLab
GitLab CI/CD можно назвать одним из самых новых и самых любимых DevOps-инженерами инструментов. Этот бесплатный опенсорсный инструмент встроен в систему контроля версий GitLab. У платформы GitLab есть community-версия, она поддерживает управление репозиториями, средства для отслеживания проблем, организацию код-ревью, механизмы, ориентированные на создание документации. Компании могут устанавливать GitLab локально, связывая эту систему с Active Directory и с LDAP-серверами для организации безопасной авторизации и аутентификации пользователей.
Вот видеоруководство, которое поможет вам узнать о том, как создавать CI/CD-конвейеры с использованием возможностей GitLab CI/CD.
Изначально GitLab CI/CD был выпущен как самостоятельный проект, но в 2015 году этот набор инструментов был интегрирован в GitLab 8.0. Отдельный GitLab CI/CD-сервер может поддерживать работу более чем 25000 пользователей. На основе подобных серверов можно создавать системы, отличающиеся высокой доступностью.
GitLab CI/CD и основной проект GitLab написаны на Ruby и на Go. Они выпущены под лицензией MIT. GitLab CI/CD, помимо обычных возможностей CI/CD-инструментов, поддерживать и дополнительные возможности, связанные, например, с планированием работ.
Интегрировать GitLab CI/CD в проект очень просто. При использовании GitLab CI/CD процесс обработки кода проекта делится на стадии, каждая из которых может состоять из нескольких задач, выполняемых в определённом порядке. Задачи поддаются тонкой настройке.
Задачи могут выполняться параллельно. После настройки последовательности стадий и задач CI/CD-конвейер готов к работе. За ходом его выполнения можно наблюдать, отслеживая состояние задач. В результате пользоваться GitLab CI/CD очень удобно, пожалуй, удобнее, чем другими подобными инструментами.
Особенности GitLab CI/CD и GitLab
GitLab CI/CD — это один из самых популярных DevOps-инструментов. Проект отличается качественной документацией, его возможностями легко и удобно пользоваться. Если вы пока не знакомы с GitLab CI/CD, следующий список возможностей этого инструмента даст вам общее представление о том, чего от него можно ожидать. Надо отметить, что многие из этих возможностей имеют отношение к самой платформе GitLab, в которую интегрирован GitLab CI/CD.
?1. Популярность
GitLab CI/CD — это сравнительно новый инструмент, нашедший широкое применение. GitLab CI/CD постепенно стал чрезвычайно популярным CI/CD-инструментом, используемым для автоматизированного тестирования и развёртывания программного обеспечения. Его просто настраивать. Это, к тому же, бесплатный CI/CD-инструмент, встроенный в платформу GitLab.
?2. Поддержка GitLab Pages и Jekyll
Jekyll — это генератор статических сайтов, который можно использовать в рамках системы GitLab Pages для создания сайтов на основе GitLab-репозиториев. Система берёт исходные материалы и генерирует на их основе готовый статический сайт. Управлять внешним видом и возможностями таких сайтов можно, редактируя файл
_config.yml, используемый Jekyll.?3. Возможности по планированию проектов
Благодаря возможности по планированию этапов проектов повышается удобство отслеживания проблем и их групп. Это позволяет управлять организацией работ по проектам, планировать их выполнение на конкретную дату.
?4. Автоматическое масштабирование CI-раннеров
Благодаря автоматическому масштабированию раннеров, ответственных за выполнение конкретных задач, можно серьёзно сэкономить на стоимости аренды серверных мощностей. Это очень важно, особенно — если речь идёт о средах, где тестирование проектов выполняется параллельно. Кроме того, это важно для крупных проектов, состоящих из нескольких репозиториев.
?5. Средства для отслеживания проблем
Мощные возможности GitLab по отслеживанию проблем привели к тому, что эту платформу используют многие опенсорсные проекты. GitLab CI/CD позволяет выполнять параллельное тестирование различных веток кода. Результаты испытаний удобно анализировать в интерфейсе системы. Это выгодно отличает GitLab CI/CD от Jenkins.
?6. Ограничение доступа к репозиториям
Платформа GitLab поддерживает ограничение доступа к репозиториям. Например, тем, кто совместно работает над проектом в некоем репозитории, можно назначить права, соответствующие их ролям. Это особенно актуально для корпоративных проектов.
?7. Активная поддержка сообщества
Вокруг GitLab сложилось активное сообщество, которое способствует развитию этой платформы и её инструментов, в частности — GitLab CI/CD. Глубокая интеграция GitLab CI/CD и GitLab, кроме прочего, упрощает нахождение ответов на вопросы, возникающие при работе с GitLab CI/CD.
?8. Поддержка работы с различными системами контроля версий
GitLab CI/CD — это система, которая способна работать не только с кодом, размещённым в репозиториях GitLab. Например, код можно хранить в GitHub-репозитории, а CI/CD-конвейер можно организовать на базе GitLab с использованием GitLab CI/CD.
Сравнение Jenkins и GitLab CI/CD
Jenkins и GitLab CI/CD — это очень хорошие инструменты, каждый из которых способен обеспечить нормальную работу CI/CD-конвейера. Но, если их сравнить, окажется, что они, хотя и во многом похожи, кое-чем друг от друга отличаются.
| Характеристика | Jenkins | GitLab CI/CD |
| Открытый или закрытый код | Открытый код | Открытый код |
| Установка | Требуется. | Не требуется, так как это — встроенная возможность платформы GitLab. |
| Уникальные особенности | Поддержка плагинов. | Глубокая интеграция в систему управления версиями. |
| Поддержка | Отсутствует. | Имеется. |
| Установка и настройка | Сложностей не вызывают | Сложностей не вызывают |
| Самостоятельное развёртывание системы | Это — единственный вариант использования системы. | Поддерживается. |
| Создание CI/CD-конвейеров | Поддерживается, используется Jenkins Pipeline. | Поддерживается. |
| Мониторинг производительности приложений | Отсутствует. | Имеется. |
| Экосистема | Существует более 1000 плагинов. | Система развивается в рамках GitLab. |
| API | Поддерживает развитую систему API. | Предлагает API для более глубокой интеграции в проекты. |
| Поддержка JavaScript | Имеется. | Имеется. |
| Интеграция с другими инструментами | Поддерживается интеграция с другими инструментами и платформами (Slack, GitHub). | Множество средств для интеграции со сторонними системами, в частности — с GitHub и Kubernetes. |
| Контроль качества кода | Поддерживается — с помощью плагина SonarQube и других плагинов. | Поддерживается. |
Различия между Jenkins и GitLab CI/CD
Описав и сравнив Jenkins и GitLab CI/CD, давайте сосредоточимся на различиях этих DevOps-инструментов. Знание об этих различиях позволит понять тех, кто предпочитает один из этих инструментов другому.
- GitLab CI/CD может полностью контролировать Git-репозитории. Речь идёт об управлении ветками репозиториев и о некоторых других возможностях. А вот Jenkins, хотя и умеет работать с репозиториями, не даёт такого же уровня контроля над ними, как GitLab CI/CD.
- Jenkins — это бесплатный опенсорсный проект. Тот, кто его выбирает, разворачивает его самостоятельно. А GitLab CI/CD включён в состав платформы GitLab, это готовое решение.
- GitLab CI/CD поддерживает развитые средства управления задачами, работающие на уровне проектов. Эта сторона Jenkins развита слабее.
Jenkins и GitLab CI/CD: сильные и слабые стороны
Сейчас у вас сложилось некоторое представление о Jenkins и GitLab CI/CD. Теперь, чтобы вы ещё лучше познакомились с этими инструментами, давайте разберём их сильные и слабые стороны. Полагаем, что вы уже приняли решение о том, какой именно инструмент вам нужен. Хочется надеяться, этот раздел позволит вам проверить себя.
?Сильные стороны Jenkins
- Большое количество плагинов.
- Полный контроль над установкой инструмента.
- Простая отладка раннеров.
- Простая настройка узлов.
- Простое развёртывание кода.
- Очень хорошая система управления учётными данными.
- Гибкость и универсальность.
- Поддержка различных языков программирования.
- Система понятна на интуитивном уровне.
?Слабые стороны Jenkins
- При использовании плагинов могут возникать сложности.
- При использовании Jenkins в маленьких проектах затраты времени, необходимые на его самостоятельную настройку, могут оказаться неоправданно большими.
- Отсутствие общих аналитических сведений по CI/CD-цепочкам.
?Сильные стороны GitLab CI/CD
- Хорошая интеграция с Docker.
- Простое масштабирование раннеров.
- Параллельное выполнение задач, входящих в состав стадий CI/CD-конвейера.
- Использование модели ориентированного ациклического графа при настройке взаимоотношений задач.
- Высокий уровень масштабируемости за счёт возможности параллельного выполнения раннеров.
- Лёгкость добавления задач.
- Простое разрешение конфликтов.
- Надёжная система безопасности.
?Слабые стороны GitLab CI/CD
- Для каждой задачи нужно описывать и загружать/выгружать артефакты.
- Нельзя протестировать результаты объединения веток до их фактического объединения.
- При описании стадий CI/CD-конвейера в них пока нельзя выделять отдельные этапы.
Итоги
И Jenkins, и GitLab CI/CD имеют сильные и слабые стороны. Ответ на вопрос о том, что именно выбрать, зависит от нужд и особенностей конкретного проекта. Каждый из рассмотренных сегодня CI/CD-инструментов отличается определёнными особенностями, хотя созданы эти инструменты для решения одной и той же задачи. При этом Jenkins — это автономный инструмент, а GitLab CI/CD — это часть платформы, предназначенной для совместной работы над кодом.
Выбирая CI/CD-систему стоит, помимо её возможностей, принимать во внимание и те затраты, которые могут быть с ней связаны, и то, с чем именно привыкли работать DevOps-инженеры, поддерживающие проект.
Какими CI/CD-инструментами вы пользуетесь?
Kopilov
Спасибо за перевод!
А о GitHub Actions у сообщества какое мнение?
Кроме отсутствия самостоятельного развёртывания системы, перед GitLab CI есть минусы?
VolCh
Привязка к гитхаб?
gecube
А в гитлаб ci будто нет привязки к гитлабу?
Да, я знаю, что можно через дополнительные функции пользоваться сборкой гитлаба, а код хранить в битбакете или гитхабе. Но… такое себе
ivankudryavtsev
Pull-сборка, это только Gitlab EE, к сожалению.
gecube
Если мы говорим про https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/ — то да
Но можно взамен использовать мирроринг репозитория https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html или внешние способы пропушить изменения в гитлаб репо (например, со стороны битбакета) и тогда при наличии gitlab-ci.yaml триггернется пайплайн. Костыли? Да, но зато премиум не нужен. Вообще удивительная вещь — жить на бесплатном гитлабе (или на стартере) вроде как можно, но эта жизнь полна боли и отчаяния, если нужно что-то из платных функций
Shatun
Пока гитхаб щупал только на своих мелких проектах, но мне нравится больше чем gitlab CI( с которым правда работал посдений раз года 2 назад)
Мне кажется что проще разделять сборку от деплоя, удобная работа с готовыми сценариями из маркета, более интуитвный интерфейс. Хотелось бы пощупать на более сложный проектах.
Чувствуется сильное влияние azure devops.
На первый взгляд при выборе gitlab CI или github CI выбрал бы github.
ahanoff
По поводу самостоятельного развертывания, есть self-hosted runners.
Вставлю свои пять копеек, мы используем у себя частично (есть также jenkins, и совсем немного bibtucket pipelines).
Так вот, github actions все еще страдает мелочными проблемами, даже несмотря на версию v2.
Список досадных мелочей и проблем, с которыми я встретился:
Плюсы для меня:
Те мелочи, которые я перечислил, не смертельны, с ними вполне можно сносно существовать, просто они портят достаточно неплохое первое впечатление от продукта. Буду благодарен, если кто-то нашел решение с уведомлениями. Спасибо
gecube
Что значит «самостоятельное» развёртывание? Покупаете гитхаб Энтерпрайз и вроде у вас все actions в периметр организации появляются автоматически, нет ?
Kopilov
Учитывая habr.com/ru/company/ruvds/blog/522334/#comment_22156126 — видимо, да… спасибо, я отстал от жизни с корпоративным self-hosted GitLab
Sergunka
Отличный вопрос по Github Actions. Для большинства случаев Actions вполне хорошо справляются тем более если проект на гитхабе, то даже дергаться не прийдется.
Sm1le291
я бы рекомендовал Azure DevOps, есть on-premises и есть бесплатная версия. Если конечно нет предвзятого отношения к продуктам Майкорсофт, что очень часто встречается)
Shatun
Сейчас работаю с azure devops-пока для меня лучший CI(сраванию с hudson/jenkins, gitlab CI, bitbucket CI, github CI).
Github CI много взял от azure devops-вполне возможно что через некоторое будет удобнее(не вижу смысла майкрософту поддерживать 2 очень похожих продукта, думаю все фичи пстепенно перкочуют в гитхаб и он станет основным инструментом от MS)
lioncub
У меня пока как раз наоборот. Gitlab в приоритете.
Azure, пока нет yaml pipeline в releases, вызывает крайнее неудобство тыканьем мышкой при создании или настройке их. Вы смирились или есть более изящные методы?
Sm1le291
я честно говоря вообще не понимаю yaml. Настраивал все билды визуально(за это и люблю собственно Azure Devops(ex-TFS)), когда плотно devops-ил. Иногда что то вручную смотрел ради интереса в json.
Именно удобный интерфейс на мой взгляд главное преимущество TFS перед тем же TeamCity. Скрипты то примерно везде работают плюс минус одинаково.
Недавно был искренне удивлен что всеми любимый TeamCity не поддерживал до последней версии conditional steps; a у нас собственно на работе сейчас не последняя версия и пригодилась бы эта фича, в AzureDevOps(TFS) например условие можно прописать прямо в браузере уже начиная с 2017 версии
lioncub
Это хорошо когда pipelin'ов немного. Но когда много проектов, и что-то нужно оптимизировать, то тут приходит боль. Пока все откроешь, перетыкаешь мышкой, каждый pipeline, каждый stage, каждый task, каждый job.
Sm1le291
Так обычно у каждой команды свои билды, даже в крупных компаниях, в частности в сбере у нас было так и в барклайс сейчас точно так же, то есть это 20-30 однотоипных билдов отилчающихся парой переменных. И все одинаковые шаги можно вынести в базовый билд дефинишен
dooMoob
Багованное недоделанное нечто.
1) Нет кеша для сборки докера -> каждый запуск пайплайна долго билдим образы.
2) Нельзя наследовать джобы, поэтому много копипаста для разных пайплайнов
3) Странное поведение при прокидывании секретов в енвы, иногда вместо секрета получаем SOME_ENV="${SOME_SECRET_NAME}"
4) Какие-то неадекватные лимиты в packages (для бесплатной версии), поэтому для хранения образов надо подключать Dockerhub
ahanoff
Команда из flipper zero, вообще, заморочились и сделали workflow для девайса своего как я понял. blog.flipperzero.one/september-progress