GitLab CI против GitHub Actions для бережливых self-hosted команд

Какая задача стоит перед основателями

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

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

Где запускаются задачи, важнее, чем многие команды ожидают. Некоторые команды довольны hosted-запусками для тестов и упаковки. Другим нужны self-hosted раннеры, потому что их приложения деплоятся на приватные машины, обращаются к внутренним сервисам или работают за строгими сетевыми правилами.

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

Инструмент также должен соответствовать привычкам работы с репозиторием. Основатели не хотят перестраивать процесс ревью только ради автоматизации. Им нужно что-то, что подходит под то, как они открывают pull request/merge request, одобряют изменения и фиксируют баги в продакшне.

Большинство команд пытаются ответить на четыре практических вопроса. Можно ли доверять сборкам и депоям без большого дополнительного операционного труда? Запускаются ли задачи в нужном месте с учётом серверов и данных? Можно ли защитить секреты, не превращая релиз в рутину? И подходит ли инструмент под существующие способы доставки кода?

Хорошая CI-настройка должна быть скучной: тихо работать, оставлять понятный след и не создавать дополнительной работы при каждом релизе.

Как инструменты ощущаются в повседневной работе

Для большинства команд спор о возможностях уходит на второй план после недели реального использования. Бóльшая проблема — ежедневное трение. Какой инструмент позволяет людям просматривать код, смотреть статус пайплайна, одобрять деплой и двигаться дальше без лишних кликов?

GitHub Actions ближе к pull request. Если команда уже работает в GitHub, это важно. Разработчик открывает pull request, ревью происходит там же, появляющиеся проверки видны в одном месте, и путь от кода до merge выглядит естественным. Для основателей, которые совмещают продуктовую и инженерную работу, такой плотный цикл легко нравится.

GitLab CI ощущается более унифицированным. Код, история пайплайнов, переменные, окружения и deploy-job'ы собраны вместе. Это сокращает переключение контекста, особенно для команд, которые управляют своими серверами и хотят видеть детали сборки и деплоя без прыжков между инструментами. Если один человек занимается и ревью кода, и операциями, GitLab часто кажется спокойнее.

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

Паттерн повторяется: стартап с двумя инженерами, код в GitHub и деплои как часть code review обычно чувствует GitHub Actions легче. Тот же стартап, который хочет единое место для контроля версий, CI, трекинга деплоев и прав команды, часто спокойнее себя чувствует в GitLab.

Текущий хост репозитория задаёт более лёгкий путь, чем многие ожидают. Переносить код ради красивого экрана CI редко окупается. Если вы уже доверяете рабочему процессу репо, начните там. Затем проверьте CI одним простым тестом: выполняется ли обычная работа с меньшим количеством договорёнок и возвратов?

Контроль раннеров и где реально запускаются задачи

Крупнейшая разница часто не в YAML. Она — в том, кто владеет машиной, на которой запускается задача, кто её патчит и к чему эта машина имеет доступ в сети.

GitHub Actions просто начать использовать, потому что hosted-раннеры доступны сразу. Вы пушите код, добавляете workflow — и задачи выполняются на стороне GitHub. Это хорошо для публичных приложений, простых сборок и команд, которым не нужен доступ к приватным серверам.

GitLab CI чаще кажется естественным, когда вы уже управляете своей инфраструктурой. GitLab тоже предоставляет shared runners, но многие self-managed команды используют раннеры на собственных Docker-хостах, кластерах Kubernetes или bare-metal машинах. Если сборка должна обращаться к приватному реестру, внутренней базе данных или серверу за Cloudflare и VPN-правилами, такая конфигурация легче поддаётся рассуждению.

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

Hosted-раннеры экономят время в начале, потому что провайдер поддерживает машины. Self-hosted раннеры дают лучший сетевой доступ и больше контроля над инструментами, кэшем и мощностью CPU. Обмен — в обслуживании: вы получаете гибкость и доступ, но берёте на себя обновления, изоляцию и очистку.

Изоляция важнее, чем многие основатели ожидают. Джоб для staging не должен совместно использовать тот же раннер и те же секреты, что production-release, если вы не уверены в границах. Аналогично для разных клиентов, сайд-проектов и экспериментальных веток.

Замапьте своё окружение перед выбором. Если команда билдит контейнеры, деплоит в Kubernetes и при этом трогает bare-metal для stateful нагрузок, явное размещение раннеров сэкономит вам проблемы. Если задачи только тестируют и публикуют маленькое приложение, hosted-раннеры, вероятно, хватят.

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

Работа с секретами в реальных командах

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

Начните с простого инвентаря. Запишите все секреты, которые использует пайплайн сегодня, даже те, что кто-то добавил ночью и не задокументировал. Большинство команд находит больше, чем ожидали.

Проще всего — разделить секреты: build-секреты, deploy-секреты, админский доступ и секреты приложения, используемые во время выполнения. Джоб, который собирает контейнер, не должен видеть те же креденшелы, что меняют инфраструктуру продакшна.

Здесь GitLab и GitHub Actions по-разному формируют практики. GitHub Actions даёт секреты на уровне репозитория, организации и окружения. GitLab предоставляет переменные на уровне проекта, группы и инстанса, плюс управления вроде protected и masked переменных. Оба варианта работают, но они склоняют команды к немного разным привычкам.

Если у компании несколько репозиториев, деплоящих в одни и те же серверы, group-переменные GitLab могут показаться естественнее. Если у каждого репо явный владелец и собственный поток релизов, scope репо и окружений в GitHub часто проще понять. Названия меню важны меньше, чем одно правило: могут ли люди предсказать, какая задача увидит какой секрет?

Правила доступа должны иметь владельца. Решите, кто вращает секреты, как часто и кто может смотреть сырые значения. В бережливых командах это обычно технический основатель или человек, выполняющий роль Fractional CTO. Это нормально на время, но процесс должен быть записан и проверен.

Одна общая хранилка для всех проектов звучит аккуратно, но часто превращается в хаос. Staging-токен просачивается в продакшн-джобы. Старый сайд-проект хранит доступ, который ему больше не нужен. Новый инженер получает слишком широкие права, потому что никто не хочет разбираться.

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

Рабочий процесс репозитория и привычки ревью

Команды редко меняют CI только из-за синтаксиса. Чаще они меняют его, потому что поток ревью либо кажется естественным, либо постоянно мешает.

Начните с того, как ваши разработчики уже открывают и одобряют изменения. Если команда живёт в GitHub и работает через pull request, GitHub Actions обычно встраивается с меньшим трением. Ревью, требуемые одобрения, защита веток и статус-чексы видны в одном потоке: увидел провал — запушил исправление — продолжил работу.

GitLab хорош, когда вы хотите, чтобы большая часть процесса релиза оставалась в одном месте. Merge request, пайплайны, окружения, deploy-job'ы и записи релизов могут быть рядом. Для бережливых команд, которые ещё и управляют своими серверами, это обычно значит меньше вкладок и меньше охоты за контекстом.

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

Ручные ворота для деплоя полезны. Некоторые команды хотят, чтобы деплой в продакшн происходил только после одобрения человека. Manual jobs в GitLab часто кажутся более встроенными для такого стиля, особенно если вы хотите видеть историю окружений рядом с пайплайном. GitHub тоже это может, через environments и approvals, но некоторым командам это кажется более рассеянным.

Теги релизов и история деплоев должны жить там, где люди реально смотрят. Если команда проверяет релизы в репо и редко открывает отдельную ops-панель — выбирайте инструмент, который делает историю очевидной. Скрытая история рождает повторяющиеся вопросы и ночные гадания.

Форма репозитория меняет ответ. В монорепо важна общая логика пайплайнов и правила по путям. В множестве маленьких репо переиспользуемые шаблоны экономят больше времени, чем сложные workflow. Если код приложения и инфраструктуры разнесён, одобрения должны оставаться понятными для обоих.

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

Как выбрать за один вечер

Долгие оценки не нужны. Короткий тест обычно даёт достаточно информации. Цель — не найти лучший инструмент на бумаге, а тот, который команда сможет поддерживать без постоянного присмотра.

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

Затем быстро оцените по карточке. Отметьте хост репо и цели деплоя. Отметьте задачи, которым нужен приватный доступ. Посчитайте, кто будет управлять раннерами и секретами каждый месяц. Протестируйте одну простую сборку и один реальный деплой в обоих инструментах. Выберите тот вариант, который требует меньше исключений и ручных правок.

Приватный доступ быстро меняет решение. Если джобу нужно добраться до внутреннего реестра, staging-базы или self-hosted серверов, место запуска задач важнее красивых экранов. Во многих маленьких командах этот один пункт решает всё.

Люди тоже важны. Если один основатель или старший инженер будет владельцем CI, выберите инструмент, который требует меньше рутинного ухода: обновления раннеров, ротации секретов, исправления прав и тех неприятных моментов, когда джоб попадает на неподходящую машину.

Держите тест преднамерённо скучным. Одна сборка, которая устанавливает зависимости и запускает тесты. Один деплой, который трогает ту же цель, что и в реальной жизни. Если инструмент требует glue-кода, неудобной работы с секретами или второй службы, чтобы добраться до серверов — запишите это против него.

Мой сдвиг прост: чище решение обычно дешевле. Если код уже в GitLab и вы держите self-hosted раннеры рядом с инфраструктурой, GitLab часто кажется прямым. Если команда живёт в GitHub и путь деплоя — в основном публичное облако, GitHub Actions обычно требует меньше усилий. Выберите то, что кажется скучным через час использования.

Простой пример: небольшая SaaS-команда с собственными серверами

Представьте пятерку разработчиков. Код в GitHub, staging на Docker Compose, продакшн — на двух приватных серверах за приватной сетью. Они не хотят публичных точек деплоя и не хотят открывать бреши в фаерволе ради CI.

В GitHub Actions простой путь — добавить self-hosted runner внутри той же сети. Раннер добирается до staging и production изнутри, так команда может деплоить по локальным маршрутам или SSH, не выставляя ничего в интернет. Если код уже в GitHub, это быстро и естественно настраивается.

GitLab CI тоже справится, и многие команды предпочитают его, когда хотят жёсткого контроля над раннерами. Self-hosted GitLab-раннер может сидеть на маленькой внутренней машине, брать только deploy-job'ы и напрямую добираться до продакшна. Это часто кажется чище для команд, рассматривающих CI как часть инфраструктуры, а не только репозитория.

Секреты — где разница становится практичной. Команда хочет одного человека, который вращает deploy-ключи, креденшелы реестра и секреты приложений, не блокируя релизы для остальных. В GitHub Actions это чаще обновление секретов репозитория или окружения в GitHub. В GitLab CI — проектные или групповые переменные с более жёсткими правилами раннеров и окружений.

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

Если важнее, где запускаются задачи, какой раннер может коснуться продакшна и как отделён доступ к деплою от обычной работы с репо, GitLab выглядит лучше. Одна сторона даёт удобство там, где уже работают разработчики. Другая — даёт более жёсткий контроль над машинами, которые делают реальную работу.

Для этой небольшой SaaS я бы оставил GitHub для ревью кода и выбирал CI по тому, кто отвечает за деплой. Если деплой делают сами разработчики, GitHub Actions часто хватит. Если за безопасную доставку на приватные сервера отвечает один человек с ops-склоном, GitLab CI даст этому человеку более крепкую опору.

Ошибки, которые создают дополнительную операционную работу

Большинство команд теряют время не потому что один CI-инструмент плох, а потому что границы настроек размыты. Основатели часто сравнивают фичи и пропускают более простой вопрос: как код переходит от pull request до живого сервера?

Этот разрыв виден сначала в секретах. Команды копируют один и тот же SSH-ключ, токен реестра и webhook-secret по репо вручную. Через три месяца никто не знает, какое значение ещё работает, кто владеет им и что сломается при ротации. Держите секреты на уровне группы, организации или окружения там, где это имеет смысл, и назначьте одного человека за ротацию.

Настройка раннеров вызывает ещё больше проблем. Один self-hosted раннер, который делает тесты, собирает контейнеры и при этом имеет доступ в продакшн, кажется эффективным в день один. Он перестаёт казаться умным, когда шаг отладки открывает токен или скрипт оказывается на живой машине. Разделяйте обязанности рано: одна группа раннеров для сборок, другая — для деплоев, с жёсткими сетевыми правилами вокруг всего, что может коснуться продакшна.

Основатели также выбирают инструмент, не замапив реальный поток релизов. Это неверно. Маленькой SaaS с двумя app-серверами, одной базой и staging не нужен сложный пайплайн сначала. Нужны ясные ответы: кто одобряет продакшн‑деплой, какие джобы требуют приватного доступа, как проходят хотфиксы, когда staging сломан, и где живут infra‑изменения.

Ещё одна ловушка — люди, а не софт. Если один инженер становится единственным, кто понимает раннеры, секреты и правила деплоев, любая проблема с пайплайном превращается в игру ожидания. Запишите настройку простым языком. Ревью CI‑изменений как кода приложения. Пусть другой инженер выполнит небольшое изменение end-to-end.

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

Быстрая проверка перед решением

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

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

Далее перечислите джобы, которые должны трогать приватные системы. Билд, который только запускает тесты — просто. Джоб для деплоя, которому нужен VPN-only доступ к базе, внутренний реестр или сервер в вашей сети — меняет картину быстро.

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

Считайте раннеры как реальные активы. Две обычные Linux‑машины управляемы для бережливой команды. Пять специализированных раннеров с разными зависимостями могут превратиться в тихую, постоянную операционную нагрузку.

Наконец, решите, что для вас значит outage. Если hosted-сервис упадёт на час — можно работать? Если релизы и внутренние задачи должны продолжаться внутри вашей сети, это важнее мелких различий в workflow.

Маленькая SaaS‑команда может быстро пройти этот тест. Если код в GitHub, деплой на пару приватных серверов и вы можете поддерживать одну‑две self-hosted машины — GitHub Actions может хватить. Если вы хотите одно место для репо, раннеров, реестра и пайплайнов на контролируемой инфраструктуре — GitLab CI часто кажется чище.

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

Что делать дальше

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

Уместите заметку на одной странице. Она должна ответить на три вещи: где запускаются задачи, как двигаются секреты и как код ревьюится и деплоится. Напишите одно предложение о том, почему вы выбрали GitLab CI или GitHub Actions. Решите, где располагаются self-hosted раннеры, кто их обновляет и какие репо могут их использовать. Запишите, как команда хранит секреты, кто их вращает и как джобы читают секреты. Опишите workflow репозитория простыми словами: правила веток, шаги ревью и кто может триггерить продакшн‑деплой.

После этого протестируйте план на одном сервисе. Выберите что-то реальное, но безопасное: внутреннее API, маленький worker или некритичное приложение. Прогоните пилот через обычный деплой, одну смену секрета и один откат. Этот небольшой тест покажет, где трение.

Держите шаги отката рядом с job'ом деплоя в том же репозитории. Не оставляйте их в вики, которую никто не открывает во время инцидента. Если кто-то может деплоить в один клик, путь отката должен быть так же доступен.

Это хорошее время для внешнего ревью. Oleg Sotnikov консультирует основателей и небольшие команды по CI, инфраструктуре и AI-first рабочим процессам через oleg.is. Если хотите второе мнение по размещению раннеров, обработке секретов или workflow репо, такой обзор поможет выбрать настройку, которая останется простой по мере роста команды.