GitHub Actions vs GitLab CI для backend, web и мобильных приложений

С чем люди сталкиваются в CI для нескольких приложений

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

Самая распространённая боль проста: одно небольшое изменение запускает слишком много работы. Правка документации может запустить подпись iOS, или правка бэкенда вынуждает полностью пересобирать веб — и внезапно каждый merge кажется медленным и рискованным.

В мульти‑апплетных настройках на ранних этапах проявляются несколько проблем:

• Runner drift: версии SDK различаются между машинами, поэтому сборки ведут себя по‑разному в CI и локально.
• Разрастание секретов: API‑ключи, сертификаты для подписи и учётные данные магазинов дублируются по задачам и окружениям.
• Путаница с кешем: неправильный ключ кеша даёт устаревшие сборки, а отсутствие кеша делает всё болезненно медленным.
• Смешанные правила релиза: backend хочется деплоить часто, а мобильные релизы — спрятаны за дополнительными проверками.
• Читаемость пайплайна: конфигурация разрастается в стену задач, до которой никто не хочет доходить.

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

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

Речь не о том, у какой платформы больше интеграций или красивее UI. Это про надёжность и удобство поддержки в день‑на‑день. Это не заменяет выбор инструментов сборки (Gradle, Xcode, Docker и т.д.), но помогает выбрать CI, который упрощает держать структуру чистой.

Как устроены GitHub Actions и GitLab CI

Крупнейшая разница — в том, как каждая платформа организует пайплайны и переиспользование, и это начинает играть роль, когда backend, web и mobile делят один репозиторий.

GitHub Actions хранит автоматизацию в YAML‑файлах под .github/workflows/. Воркфлоу срабатывают по событиям: push, pull request, расписание или ручной запуск. GitLab CI сосредоточен вокруг файла .gitlab-ci.yml в корне репозитория, с опциональными include, и пайплайны обычно запускаются по пушам, merge request’ам, расписаниям и ручным задачам.

GitLab выстроен вокруг стадий. Вы определяете стадии (build, test, deploy), затем назначаете задачи стадиям, которые выполняются по порядку. GitHub Actions — это воркфлоу с задачами: задачи по умолчанию выполняются параллельно, а зависимости добавляются, если что‑то должно ждать.

Если нужно прогнать одну и ту же логику по множеству целей, матричные сборки в GitHub естественно подходят (iOS vs Android, разные версии Node). GitLab может дать аналогичный фэн‑аут через parallel jobs и переменные, но часто придётся самому больше связывать компонентов.

Переиспользование тоже выглядит по‑разному. В GitHub команды обычно опираются на reusable workflows и composite actions. В GitLab переиспользование часто делается через include, общие шаблоны и YAML‑якоря/extends.

Одобрения и защищённые окружения тоже отличаются. В GitHub часто используют protected environments с обязательными ревьюерами и переменными окружения, привязанными к окружению, чтобы продакшен‑деплой приостанавливался до одобрения. В GitLab обычно комбинируют защищённые ветки/теги, защищённые окружения и ручные задачи, так что только определённые роли могут запускать деплой.

Настройка раннеров и выполнение задач

Именно в настройке раннеров две платформы начинают ощущаться по‑разному в повседневной работе. Обе могут запускать задачи на hosted раннерах (машиной не управляете вы) или на self‑hosted раннерах (вы владеете машиной, обновлениями и безопасностью). Hosted‑раннеры проще для старта; self‑hosted часто нужны ради скорости, особых инструментов или доступа к внутренним сетям.

Практическое разделение для многих команд: Linux‑раннеры для backend и web, и macOS‑раннеры только когда нужно собирать iOS. Android можно собирать на Linux, но сборки тяжёлые, поэтому размер раннера и дисковое пространство имеют значение.

Hosted vs self-hosted: что вы управляете

Hosted‑раннеры подходят, когда нужна предсказуемая настройка без поддержки. Self‑hosted имеют смысл, если нужны конкретные версии Java/Xcode, более быстрые кеши или доступ к внутренним сетям.

Если вы берёте self‑hosted, определите роли раннеров заранее. Большинству репозиториев подходит небольшой набор: общий Linux‑раннер для backend/web, более мощный Linux‑раннер для Android, macOS‑раннер для упаковки и подписи iOS и отдельный раннер для деплоев с ужесточёнными правами.

Выбор раннера для задачи

Обe системы позволяют нацеливать задачи на конкретные раннеры (labels в GitHub, tags в GitLab). Держите имена, привязанные к рабочим нагрузкам: linux-docker, android или macos-xcode15.

Изоляция — частая причина флейковости сборок. Оставшиеся файлы, общие кеши, которые портятся, или инструменты, установленные «вручную» на self‑hosted машине, могут давать случайные ошибки. Чистые рабочие пространства, зафиксированные версии инструментов и плановая очистка раннеров быстро окупаются.

Вместимость и права — ещё две повторяющиеся боли, особенно с доступностью и стоимостью macOS. Хороший по умолчанию план: билд‑раннеры собирают, деплой‑раннеры деплоят, а продакшен‑учётные данные хранятся в минимально необходимом наборе задач.

Секреты и переменные окружения

Секреты — это место, где мульти‑апп CI пайплайны становятся рискованными. Основы похожи (хранить секреты в платформе, подставлять их во время выполнения), но уровень детализации и разграничение отличаются.

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

GitLab CI использует CI/CD переменные на уровне проекта, группы или инстанса. Также поддерживаются переменные, привязанные к окружениям, и защиты вроде "protected" (доступно только на защищённых ветках/тегах) и "masked" (скрыто в логах). Эти механизмы полезны, когда один монорепозиторий обслуживает несколько команд.

Главная ошибка — случайное раскрытие: отладочный вывод, упавшая команда, которая эхоит переменные, или артефакт, случайно включающий конфигурационный файл. Рассматривайте логи и артефакты как доступные для совместного чтения по умолчанию.

В пайплайнах backend + web + mobile секреты обычно включают облачные креденшелы, URL баз данных и сторонние API‑ключи, материалы для подписи (iOS‑сертификаты/профили, Android keystore и пароли), токены реестров (npm, Maven, CocoaPods) и автоматизационные токены (email/SMS провайдеры, чат‑боты).

Для нескольких окружений (dev, staging, prod) держите имена согласованными и меняйте значения по области окружения, а не копируйте задачи. Это упрощает ротацию и контроль доступа.

Пара правил, которые предотвращают большинство инцидентов:

• Предпочитайте короткоживущие креденшелы (например, OIDC к облачным провайдерам, когда доступно) вместо долгоживущих ключей.
• Применяйте принцип наименьших привилегий: отдельные учётные записи для деплоя backend, web и mobile.
• Маскируйте секреты и избегайте печати переменных окружения, даже при ошибках.
• Ограничивайте продакшен‑секреты защищёнными ветками/тегами и обязательными одобрениями.
• Никогда не храните секреты в артефактах сборки, даже временно.

Простой, но эффективный пример: мобильные задачи должны получать секреты подписи только при тегированных релизах, в то время как backend‑деплой может использовать ограниченный deploy‑токен при слиянии в main. Это значительно уменьшает радиус поражения при неверной конфигурации задачи.

Кеширование и артефакты для ускорения сборок

Большинство медленных пайплайнов медленны по одной скучной причине: они заново скачивают и пересобирают одно и то же снова и снова. Кеширование избегает повторной работы. Артефакты решают другую задачу: сохранить точный вывод конкретного прогона.

Что кешировать зависит от того, что вы собираете. Backend выигрывает от кешей зависимостей и кешей компилятора (например, кеш модулей Go). Веб‑сборки выигрывают от кешей менеджеров пакетов и инструментов сборки. Мобильные сборки часто нуждаются в кеше Gradle и Android SDK на Linux, и кешах CocoaPods или Swift Package Manager на macOS. Будьте осторожны с агрессивным кешированием вывода iOS (DerivedData), если вы не понимаете компромиссы.

Обе платформы следуют общей схеме: восстановить кеш в начале задачи, сохранить обновлённый кеш в конце. Разница в повседневности — в контроле. GitLab делает поведение кеша и артефактов явным в одном файле, включая срок хранения. GitHub Actions часто полагается на отдельные actions для кеша: гибко, но проще сделать ошибку в конфиге.

Ключи кеша важнее в монорепозиториях. Хорошие ключи меняются, когда входы меняются, и остаются стабильными иначе. Lockfile’ы (go.sum, pnpm-lock.yaml, yarn.lock и т.п.) должны задавать ключ. Также полезно включать хеш конкретной папки приложения, которую вы собираете, вместо всего репозитория, и держать отдельные кеши на приложение, чтобы одно изменение не инвалидировало всё.

Используйте артефакты для тех результатов, которые вы хотите сохранить от конкретного прогона: релизные бандлы, APK/IPA, отчёты тестов, файлы покрытия и метаданные сборки. Кеши — ускорение; артефакты — запись.

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

Подход монорепозитория: несколько пайплайнов без хаоса

Монорепозиторий становится беспорядком, когда каждый пуш запускает тесты backend, сборку web и подпись mobile, даже если изменили только README. Чистый паттерн — определить, что изменилось, и запускать только нужные задачи.

В GitHub Actions это часто означает отдельные воркфлоу для каждого приложения с фильтрами по путям, чтобы воркфлоу запускался только при изменениях в своей зоне. В GitLab CI чаще используют rules:changes (или дочерние пайплайны), чтобы создавать или пропускать группы задач на основе путей.

Общие пакеты — где рушится доверие. Если packages/auth изменился, и backend, и web могут потребовать пересборки, даже если их папки не менялись. Обращайтесь с общими путями как с триггерами для нескольких пайплайнов и держите границы зависимостей ясными.

Простая карта триггеров, которая снижает сюрпризы:

• Backend‑задачи запускаются при изменениях в backend/** или packages/**.
• Web‑задачи запускаются при изменениях в web/** или packages/**.
• Mobile‑задачи запускаются при изменениях в mobile/** или packages/**.
• Изменения только в доках запускают быстрые проверки (форматирование, проверка орфографии).

Параллелите безопасное (unit tests, linting, web build). Последовательно выполняйте то, что требует контроля (деплои, релизы в сторы). И needs в GitLab и зависимости задач в GitHub помогают вам запускать быстрые проверки первыми и останавливать остальное при провале.

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

Шаг за шагом: чистый пайплайн для backend, web и mobile

Читабельный мульти‑апп пайплайн начинается с имен, которые сразу дают понять намерение. Выберите один паттерн и придерживайтесь его, чтобы люди могли бегло просматривать логи и понимать, что запустилось.

Одна схема, которая остаётся понятной:

• Пайплайны: pr-checks, main-build, release
• Окружения: dev, staging, prod
• Артефакты: backend-api, web-bundle, mobile-debug, mobile-release

Далее держите задачи маленькими и продвигайте дальше только то, что прошло ранние проверки:

1. PR checks (каждый pull request): запускайте быстрые тесты и линт только для приложений, которые изменились. Для backend соберите деплойный артефакт (контейнерный образ или бандл сервера) и сохраните его, чтобы последующие шаги не пересобирали его.

2. Веб‑сборка (PR + main): собирайте веб‑приложение в статический бандл. В PR сохраняйте вывод как артефакт (или деплойте в preview, если он у вас есть). В main производите версионированный бандл для dev или staging.

3. Мобильные debug‑сборки (только PR): собирайте debug APK/IPA без подписи для релиза. Цель — быстрый фидбек и файл, который тестеры могут установить.

4. Релизные сборки (только теги): при пуше тега вроде v1.4.0 выполняйте полные backend и web‑сборки плюс подписанные мобильные релизы. Генерируйте store‑ready артефакты и храните релизные заметки рядом с артефактами.

5. Ручные одобрения: ставьте одобрения между staging и prod, а не перед базовым тестированием. Разработчики могут запускать сборки, но только утверждённые роли должны деплоить в прод и иметь доступ к продакшен‑секретам.

Распространённые ошибки, которые отнимают время

Команды часто теряют недели из‑за рабочих привычек, которые незаметно создают флейковые сборки.

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

Секреты — ещё один источник проблем. Ключи подписи и сертификаты мобильных приложений легко потерять в управлении. Частая ошибка — хранить их слишком широко (доступными каждой ветке и задаче) или случайно печатать их в логах. Ограничьте материалы для подписи защищёнными ветками/тегами и избегайте шагов, которые печатают секреты (даже base64).

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

И, наконец, в монорепозитории триггерить все пайплайны на каждое изменение — это растрата минут и терпения. Если кто‑то поправил README и вы пересобираете iOS, Android, backend и web, люди перестают доверять CI.

Быстрый чек‑лист, который помогает:

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

Быстрые проверки перед выбором платформы

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

Сосредоточьтесь на:

• Плане по раннерам: hosted, self‑hosted или микс. Мобильные сборки часто тянут команды к миксу, потому что iOS требует macOS.
• Плане по секретам: где хранятся секреты, кто может их читать и как проходит ротация. Продакшен должен быть строже, чем staging.
• Плане кеширования: что кешируется, где хранится и как формируются ключи. Если ключ меняется при каждом коммите, вы платите, но не ускоряете работу.
• Плане монорепозитория: фильтры по путям и понятный способ делиться общими шагами (lint, тесты) без copy‑paste.
• Плане релизов: теги, одобрения и разделение окружений. Будьте явными, кто может продвигать в прод и какие доказательства нужны.

Протестируйте эти ответы на простом сценарии. В монорепозитории с Go backend, Vue вебом и двумя мобильными приложениями: правка в документации должна почти ничего не делать; изменение в backend должно запустить тесты и собрать артефакт API; изменение мобильного UI — собрать только Android и iOS.

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

Пример: реалистичный поток сборки и релиза для монорепозитория

Представьте один репозиторий с тремя папками: backend/ (Go), web/ (Vue) и mobile/ (iOS и Android).

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

Практическое разделение:

• Фичевые ветки: запускайте lint + unit tests для изменённых частей, собирайте backend и web, и опционально делайте Android debug‑сборку. Пропускайте iOS, если это не нужно.
• Тегированные релизы: запускайте всё, создавайте версионированные артефакты, подписывайте мобильные приложения и отправляйте образы/бинарники в хранилище релизов.

Выбор раннеров меняется, когда появляется мобильная часть. Go и Vue хорошо живут на Linux почти везде. iOS требует macOS‑раннеров, что может перевесить решение. Если команда хочет полный контроль над машинами, GitLab CI с self‑hosted раннерами удобнее держать флот. Если вы предпочитаете меньше операционной работы и быстрое поднятие, hosted‑раннеры GitHub удобны, но минуты macOS и их доступность становятся фактором планирования.

Кеширование — где реально экономится время, но лучший кеш отличается по приложению. Для Go кешируйте загрузки модулей и build cache. Для Vue кешируйте store менеджера пакетов и перестраивайте только при изменении lockfile’а. Для mobile кешируйте Gradle и Android SDK на Linux; на macOS кешируйте CocoaPods или SPM, ожидая больших кешей и более частой инвалидации.

Правило принятия решений, которое выдерживает проверку: если код уже хостится на одной платформе, начните там. Меняйте только если раннеры (особенно macOS), права или соответствие вынуждают.

Следующие шаги: выбрать, стандартизировать и автоматизировать безопасно

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

Начните просто: по одному пайплайну на приложение (backend, web, mobile). Как только это стабильно, вынесите общие шаги в переиспользуемые шаблоны, чтобы уменьшить copy‑paste, не размывая ответственность.

Запишите области видимости секретов так, как вы записали бы, кому выдали ключи от офиса. Продакшен‑секреты не должны быть доступны каждой ветке. Установите напоминание о ротации (ежеквартально лучше, чем никогда) и согласуйте процедуру экстренной отзыва ключей.

Если вы используете no‑code генератор, который выдаёт реальный исходный код, рассматривайте генерацию/экспорт как первоклассный CI‑шаг. Например, AppMaster (appmaster.io) генерирует Go backend, Vue3 веб‑приложения и Kotlin/SwiftUI мобильные приложения, поэтому пайплайн может регенерировать код при изменениях и затем собирать только затронутые цели.

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