Стоит ли использовать действия GitHub или автономный сервер сборки?

GitHub Actions — это платформа CI/CD, которая позволяет разработчикам автоматически создавать, тестировать и развертывать приложения на GitHub без использования каких-либо внешних инструментов.

GitHub Actions — это платформа CI/CD, которая позволяет разработчикам автоматически создавать, тестировать и развертывать приложения на GitHub без использования каких-либо внешних инструментов. Учитывая простоту использования, нужен ли вам внешний сервер сборки?

Действия GitHub

CI/CD — это процесс автоматической сборки и развертывания приложений, обычно с помощью автоматизированного «конвейера сборки», который принимает ваш код, запускает сценарий сборки и развертывает его там, где это необходимо. Конвейеры сборки обычно управляются внешним программным обеспечением сервера сборки, например TeamCity, Travis CI или Jenkins, которые являются стандартными инструментами для управления всем, что связано с CI/CD.

Однако их, как правило, сложно настроить, и именно здесь GitHub Actions предлагает альтернативу для повседневных программистов. Он намного проще и часто бесплатен для большинства пользователей, и, несмотря на то, что это бесплатный инструмент, он не уступает проприетарным решениям, особенно благодаря недавним обновлениям и поддержке сообщества.

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

Для большинства типов приложений уже созданы шаблоны, а это означает, что автоматическое создание вашего приложения обычно так же просто, как щелкнуть вкладку «Действия» в вашем репозитории и настроить предварительно созданный шаблон. GitHub может даже порекомендовать вам один из них, исходя из вашей кодовой базы:

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

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

Используя торговую площадку, GitHub Actions может делать практически все, что могут другие автономные решения, просто приложив немного больше усилий вручную. В конце концов, он просто запускает базовые сценарии в системе Linux или Windows.

Например, такие инструменты, как Jenkins, предлагают интеграцию с программным обеспечением для управления проблемами, таким как Jira или Trello, или интеграцию журналирования со Slack. Они встроены в программное обеспечение и просты в настройке, а также являются отличным аргументом в пользу автономных систем сборки. Однако действия GitHub также можно настроить для выполнения всех этих задач, настроив инструменты из магазина.

Одним из самых больших недостатков GitHub Actions является структура ценообразования. Каждая учетная запись GitHub или организация имеет определенное количество минут сервера сборки, которое используется всеми репозиториями. Каждая минута, которую сервер GitHub тратит на выполнение вашей сборки, использует минуты из этого сегмента. Уровень бесплатного пользования составляет 2000 минут, или вдвое меньше для Windows, чего более чем достаточно для большинства обычных пользователей.

Вы можете заплатить больше за GitHub Pro, Team или Enterprise за больше минут, но вы также можете полностью обойти эту проблему, предоставив свой собственный автономный раннер. Если у вас есть дополнительный сервер, вы можете довольно быстро настроить его для приема задач GitHub Actions. В зависимости от производительности этого сервера он может быть даже значительно быстрее, чем общий хостинг GitHub Action. Чтобы узнать больше, вы можете прочитать наше руководство по настройке собственных бегунов с автономным размещением.

В целом, GitHub Actions отлично подходит для любителей и работает достаточно хорошо, поэтому у большинства небольших команд не возникнет проблем при создании своих проектов с использованием этого сервиса.

Внешние серверы сборки

С другой стороны, внешний сервер сборки, такой как Jenkins или TeamCity, обычно предоставляет более продвинутые функции для создания, тестирования и развертывания приложений и обычно предпочитается более крупными командами и корпорациями из-за большей гибкости.

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

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

Отделение системы сборки от системы контроля версий также обеспечивает большую гибкость в выборе инструментов и услуг. Например, если вы хотите использовать альтернативные решения для контроля версий, такие как Gitlab или BitBucket, вы можете легко заменить их, не внося никаких изменений в конфигурацию вашего сервера сборки. С GitHub Actions вы практически полностью привязаны к использованию GitHub.

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

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

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

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