И GitHub Actions, и Дженкинс выполняют свою работу. Давайте выясним, стоит ли рассматривать возможность переезда из Дженкинса.
За последние несколько лет DevOps стал важной частью жизненного цикла программного обеспечения. Это стимулировало рост многих ведущих инструментов и практик DevOps. Вы можете найти ряд инструментов для поддержки процесса CI / CD. Среди них выделяются Jenkins и GitHub Actions.
В этой статье я сравню GitHub Actions с Jenkins и расскажу, как сделать правильный выбор.
Введение в действия Jenkins и GitHub
Начнем с Дженкинса. Вот краткое описание,
«Jenkins - это бесплатный сервер автоматизации с открытым исходным кодом. Он помогает автоматизировать части разработки программного обеспечения, связанные со сборкой, тестированием и развертыванием, облегчая непрерывную интеграцию и непрерывную поставку ». ~ Из Википедии
Точно так же GitHub Actions является последним из двух, предлагаемых GitHub в качестве SaaS-предложения.
«GitHub Actions теперь упрощает автоматизацию создания, тестирования и развертывания проектов на любой платформе, включая Linux, MacOS и Windows. Запустите свои рабочие процессы в контейнере или на виртуальной машине ». ~ Из блога GitHub
Прежде чем решать, стоит ли переходить, давайте разберемся, кому вообще стоит это учитывать.
Стоит ли рассматривать переход от Дженкинса?
Если у вас все работает с Jenkins, вы уверены в своей настройке, но при этом имеете полный контроль и стоимость не проблема, я бы порекомендовал остаться с Jenkins.
Для тех, кто использует GitHub в качестве платформы управления версиями и уже чувствует, что вы не уверены в своей настройке Jenkins и ищете лучшую альтернативу, действия GitHub станут основным выбором для рассмотрения.
Поскольку GitHub Actions - это полностью управляемая служба GitHub, вам не нужно знать, как масштабировать и управлять инфраструктурой для ее запуска.
Это основная причина, по которой я решил уйти из Jenkins, где я не мог полностью контролировать то, что происходило с моими конвейерами CI / CD.
Некоторые из проблем, с которыми мне пришлось столкнуться;
- Обновление плагинов.
- Моя единственная сборка сервера Jenkins стоит денег, даже если я не запускаю никаких сборок.
- Несоответствие в параллельных сборках.
- Мне пришлось полагаться на несколько плагинов, которые поставляются с обновлениями, с которыми мне время от времени приходится иметь дело.
Я знаю, что с Jenkins есть решения для решения некоторых из этих проблем, но меня хватило, и я перешел на управляемую платформу.
Надеюсь, я настроился правильно и перешел на GitHub Actions, если это применимо к вам. Давайте посмотрим на функции, которые предлагает GitHub Actions, чтобы рассмотреть этот шаг.
Легкость настройки - все это управляется GitHub
На мой взгляд, первым и главным плюсом GitHub Actions над Jenkins является простота настройки в GitHub Actions. Действия GitHub работают в облаке. У вас также есть возможность запустить его локально, что называется раннером. Напротив, у Jenkins нет официально управляемого предложения услуг.
И я мог бы не пойти на какие-либо сторонние управляемые предложения для Jenkins. Я считаю, что передавать доступ к исходному коду и конфиденциальной информации стороннему провайдеру слишком рискованно.
По этой причине сервер Jenkins требует установки, тогда как GitHub Actions не нуждается. Следовательно, процесс настройки в GitHub Actions очень удобен. Кроме того, GitHub Actions - это серия запусков докеров. Для этого требуются только docker build и docker run. Это упрощает запуск и отладку.
Тесная интеграция с GitHub - безупречный опыт
Поначалу Jenkins кажется более гибким, чем GitHub Actions. Jenkins в основном основан на учетных записях и триггерах и сосредотачивается на сборках. Они не соответствуют событиям GitHub. В отличие от этого, действия GitHub охватывают широкий диапазон. Таким образом, для каждого события GitHub существует действие GitHub.
Действия GitHub поддерживают множество языков и фреймворков, и они также написаны на YAML. Следовательно, их можно редактировать, повторно использовать, публиковать и разветвлять так же, как и код.
Его просто использовать с GitHub, потому что при форке репозитория действия автоматически форкуются.
Это позволяет очень эффективно тестировать и строить проекты и даже приближать их к разработчику. Кроме того, у вас есть доступ к API GitHub, что делает его более популярным среди разработчиков.
Один из популярных вариантов использования такой тесной интеграции можно увидеть при использовании Bit (Github). Bit - это инструмент и платформа, которые упрощают совместное использование JS-компонентов (Node, React, Vue, Angular и т. Д.) Из любого репозитория в облачную службу Bit, а оттуда в другие репозитории.
Облачный сервис Bit может автоматически генерировать pull-запросы ко всем репозиториям Github, на которые влияет изменение одного общего компонента. Эти автоматически сгенерированные PR могут служить триггерами для действий Github.
- Все это означает, что изменение, внесенное в один единственный (общий) компонент, может распространяться на все использующие его репозитории, вызывая CI, которые проверяют, что ничего не сломалось во всех проектах 😮
Подробнее об интеграции Bit ‹› Github читайте здесь.
Еще одна замечательная особенность GitHub Actions заключается в том, что ими можно делиться друг с другом через GitHub Marketplace. Вы можете повторно использовать Действия, написанные другими разработчиками, что может сэкономить вам достаточно времени и избежать перезаписи уже доступного кода.
Координатор и узлы сборки - созданы для масштабирования
Действия GitHub по умолчанию следуют шаблону master-slave (координатор и узлы сборки), в отличие от последовательного конвейера, который предлагает нам Дженкинс.
Однако важно отметить, что аналогичная установка возможна с Jenkins, но для ее настройки и запуска потребуются дополнительные усилия и знания.
Если вы используете Jenkins, настройка по умолчанию будет запускать каждый шаг в конвейере развертывания синхронно. Например, если вам нужно запустить модульные тесты, интеграционные тесты и некоторые проверки сонара, они должны будут выполняться в среде с одним сервером. Это может задержать выполнение в зависимости от доступных ресурсов на вашем сервере. Кроме того, вам не придется прилагать дополнительных усилий для обеспечения надежности трубопроводов.
С помощью GitHub Actions их можно распараллелить, как показано на изображении выше. например, задание 1 может быть модульным тестом и тестом интеграции, задание 2 может быть проверкой сонара.
Резюме
Мы критически рассмотрели несколько областей, в которых действия GitHub предшествуют Jenkins в том, что касается их преимуществ. Более того, GitHub Actions растут быстрее, чем Jenkins, где тысячи GitHub Actions публикуются на торговой площадке GitHub. Сообщество вокруг этого также улучшается, поскольку есть специальные репозитории для GitHub Actions. Что это обозначает?
Толпе это нравится!
Давайте посмотрим на краткое изложение сравнения.
Однако, используете ли вы в своем проекте GitHub Actions или Jenkins, решать вам. В настоящее время GitHub Actions можно бесплатно использовать для общедоступных репозиториев. Для частных репозиториев есть механизм оплаты по мере использования.
Надеюсь, вы уже поняли, что GitHub Actions - это преобладающий выбор по сравнению с Jenkins, в основном из-за его гибкости. Для тех, кто начинает новый проект или использует GitHub в качестве платформы управления версиями, нетрудно перейти к действиям GitHub.
Для начала, документация GitHub предоставляет точные шаги для этого. Синтаксис рабочего процесса для GitHub Actions можно найти здесь.
Надеюсь, вам понравилась статья. Спасибо за прочтение !!
