CI/CD на open source: GitLab CE vs Gitea + Drone для команд

Задача: один процесс разработки, а не набор скриптов

Во многих командах CI/CD начинается с пары bash-скриптов на одном сервере. Пока проектов мало, это работает. Но затем появляется хаос: сборки падают "иногда", релизы зависят от одного человека, а доступы и секреты живут в случайных местах.

Обычно болит не сам pipeline, а то, что вокруг него:

• непредсказуемые сборки из-за разных окружений и версий
• ручные релизы и откаты без понятной истории
• доступы "на доверии", без ролей и процесса
• аудит: кто запустил деплой и что именно изменилось
• секреты в переменных, файлах и чатах, без контроля

Поэтому многие выбирают CI/CD на open source, особенно для on-prem. Так проще контролировать, где хранятся исходники, кто к ним имеет доступ, как устроен аудит, и что происходит с данными при обновлениях и инцидентах. Это важно и для небольших продуктовых команд, и для организаций с жесткими требованиями ИБ (госсектор, финансы, медицина, образование).

Ниже два практичных подхода.

GitLab CE - это "все в одном": репозитории, issue-трекинг, CI, registry и права доступа в одной системе.

Gitea + Drone - это набор компонентов: легкий Git-сервер (Gitea) плюс отдельная система CI (Drone) и, при необходимости, дополнительные сервисы вокруг (хранилище артефактов, registry, секреты).

Материал пригодится, если вы выбираете решение под размер команды, количество проектов и интеграции (например, LDAP/AD, уведомления, артефакты), а также если вам предстоит миграция репозиториев без потери истории и с минимальной остановкой работы.

Два подхода: все в одном или набор компонентов

Когда вы строите CI/CD на open source, обычно выбирают один из двух путей: взять одну большую платформу, где почти все уже есть, или собрать набор небольших инструментов под свои правила.

GitLab CE - монолитная платформа вокруг Git и CI. В одном интерфейсе вы получаете репозитории, merge request, встроенный CI, базовые политики доступа, журналирование, управление раннерами и много мелких удобств, которые экономят время на старте. Минус тоже понятный: обновления и настройка часто тяжелее, а лишние функции иногда мешают строгим требованиям ИБ.

Gitea - легкий Git-сервер, а Drone - отдельный CI. Такой набор проще держать минимальным: меньше функциональности в каждом сервисе, проще изолировать, легче переносить между средами. Но "склеивать" придется вам: роли, единый вход, правила хранения секретов, шаблоны пайплайнов, наблюдаемость.

Разница на практике обычно сводится к простому:

• GitLab CE быстрее дает единый процесс и меньше решений "как сделать"
• Gitea + Drone дает больше свободы в архитектуре и изоляции, но требует больше инженерной дисциплины
• в монолите проще обучать команду, в наборе компонентов проще менять отдельные части
• в монолите выше цена ошибки при обновлении, в модульной схеме больше точек интеграции

Что бы вы ни выбрали, почти всегда нужны еще несколько обязательных вещей. Без них CI/CD быстро превращается в набор костылей: реестр артефактов и образов (контейнеры, пакеты, бинарники), хранилище секретов и правила ротации (токены, ключи, пароли), мониторинг и алерты для раннеров и очередей, бэкапы и регулярная проверка восстановления.

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

Как выбрать по масштабу команды и числу проектов

Выбор между GitLab CE и связкой Gitea + Drone обычно упирается не в "что лучше", а в то, сколько у вас людей и репозиториев, и насколько едиными должны быть правила для всех. Важно, чтобы инструмент рос вместе с командой, а не заставлял переписывать процессы каждые полгода.

Если у вас один репозиторий и 5-10 человек, выигрывает простота. GitLab CE часто проще объяснить новичкам: репозиторий, issues, merge requests и пайплайны в одном месте. Gitea + Drone тоже поднимается быстро, но вам придется заранее договориться, где "живут" правила ревью, где хранятся секреты, кто отвечает за обновления двух систем, и как люди находят нужные настройки.

Когда появляется несколько команд и десятки проектов, начинают ощущаться "стыки". В GitLab CE легче закрепить единые шаблоны пайплайнов, права, группы и правила веток. В Gitea + Drone это тоже возможно, но чаще требует аккуратных соглашений и дисциплины: шаблоны конфигов, общие плагины, единая схема именования репозиториев и окружений.

При сотнях проектов проявляется нагрузка на администрирование: учет прав, аудит изменений, обслуживание раннеров, рост числа интеграций. Здесь важно не только "умеет ли система", но и сколько времени она будет отнимать у тех, кто ее поддерживает.

Ориентиры по масштабу:

• 1-10 репозиториев: берите то, что быстрее внедрить и проще обучить (часто GitLab CE)
• 10-100 репозиториев: выбирайте решение, где проще держать единые правила и шаблоны (часто GitLab CE, но связка тоже работает при хороших стандартах)
• 100+ репозиториев: оценивайте нагрузку на админов, удобство групповых настроек и предсказуемость обновлений

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

Требования ИБ: доступы, аудит, секреты и изоляция

В CI/CD на open source чаще всего ошибаются не в пайплайнах, а в правах, секретах и раннерах. Если это не продумать, любой удобный инструмент превращается в риск для кода и инфраструктуры.

Роли и права: кто что может

Проверьте, можно ли отдельно управлять тремя вещами: кто видит репозитории, кто имеет право запускать пайплайны, и кто может мержить в защищенные ветки. В небольших командах эти роли часто совпадают, но в компаниях с несколькими проектами важно разделение. Например, подрядчик может иметь доступ к коду и к Merge Request, но не к запуску деплоя в прод.

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

Аудит, секреты, изоляция и сеть

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

Секреты (токены, пароли, ключи) чаще всего "утекают" из-за простых ошибок: их кладут в репозиторий, они попадают в логи, или пайплайнам дают слишком широкие права. Практичнее хранить секреты в защищенных переменных, давать доступ по окружениям (dev/stage/prod) и ограничивать, какие ветки могут их использовать.

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

Минимальный набор практик, который почти всегда окупается:

• отдельные раннеры для доверенных и недоверенных проектов
• запрет privileged-режима там, где он не нужен
• сетевые правила: раннер из CI видит только нужные сервисы
• деплой в прод только из защищенных веток и с ручным подтверждением
• отдельные учетные записи и ключи для CI, без прав человека-админа

Если пайплайн имеет доступ к продакшену, считайте его таким же критичным, как VPN или bastion: сегментация сети и минимальные права здесь важнее удобства.

Интеграции: что реально потребуется в вашей работе

Интеграции часто влияют на выбор сильнее, чем скорость раннеров. В CI/CD на open source важен не список галочек, а то, сколько внешних систем у вас уже есть и кто будет поддерживать связки.

Минимальный набор интеграций

Почти всем нужны единые учетные записи. Самый частый сценарий - подключить корпоративный каталог пользователей (LDAP/AD), чтобы не заводить людей вручную и быстро закрывать доступ при увольнении. Для организаций с жесткими требованиями ИБ нередко требуется SSO по SAML и понятный аудит: кто вошел, кто выдал права, кто запустил пайплайн.

С трекерами задач и мессенджерами стоит быть прагматичными. Обычно критично одно: привязка коммитов и merge request к задаче и уведомления о статусе сборки в командный чат. Остальное приятно, но редко окупает сложность.

Отдельный вопрос - где хранить контейнерные образы, артефакты сборки и пакеты. В GitLab это часто решается встроенными возможностями, а в связке Gitea + Drone обычно добавляют отдельные хранилища. В обоих случаях заранее продумайте правила очистки: сколько хранить артефакты, как удалять старые теги образов, кто утверждает исключения. Иначе место закончится неожиданно.

Быстрый способ понять, где будет больше работы у команды:

• Нужны ли SSO и роли из каталога (и какие: группы, отделы, проекты)?
• Какие уведомления реально используются каждый день (чат, почта, трекер)?
• Где будут жить образы и пакеты, и есть ли политика retention?
• Сколько внутренних систем потребуют webhooks и API (CMDB, портал заявок, сканеры ИБ)?
• Кто будет поддерживать интеграции после запуска?

Kubernetes и инфраструктура как код

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

Пример: команда в госорганизации хранит Terraform и Ansible рядом с кодом приложения и обязана показывать аудит изменений. Если вам важны единые логи, прозрачные права и меньше самописных скриптов, лучше сразу выбирать вариант, который закрывает это "из коробки", а доработки оставить только для действительно уникальных процессов.

Эксплуатация: обновления, бэкапы, мониторинг, восстановление

Эксплуатация часто решает судьбу CI/CD сильнее, чем набор функций. GitLab CE - это один большой сервис с кучей встроенного (репозитории, CI, пользователи, часто еще контейнерный реестр). Связка Gitea + Drone - несколько отдельных компонентов, которые проще по отдельности, но их больше, и их нужно держать в одном ритме.

По обновлениям: у GitLab релизы выходят регулярно, и апгрейд обычно требует больше внимания к совместимости версий и времени простоя. Зато точек обновления меньше. В варианте Gitea + Drone вы планируете окна обслуживания чаще, но риск "поломки цепочки" выше: обновили один компонент, а другой стал вести себя иначе.

Бэкапы тоже считаются по количеству частей. В GitLab нужно уметь восстанавливать не только Git-репозитории, но и базу данных, артефакты CI, пакеты и настройки. В связке Gitea + Drone обычно отдельно живут репозитории, база, конфиги, секреты, кэш и хранилище артефактов (если вы его добавляете). Чем больше сервисов, тем важнее регулярная проверка восстановления, а не только факт "бэкап делается".

Наблюдаемость: метрики, логи и алерты должны быть назначены на конкретного владельца. Если никто не дежурит и не смотрит алерты, их как будто нет. Минимум стоит отслеживать заполнение диска (артефакты растут быстро), очереди раннеров, ошибки 5xx, время ответа веб-интерфейса и падения задач.

Восстановление после сбоя удобно описывать двумя метриками. RPO - сколько данных вы готовы потерять (например, до 15 минут). RTO - как быстро сервис должен вернуться (например, до 2 часов). Для команды из 10 человек это одни цифры, для критичных систем и регуляторных требований - другие.

С первого дня заложите:

• раздельные окружения (prod и тест для обновлений)
• расписание бэкапов и периодические тесты восстановления
• лимиты хранения для артефактов и логов
• базовые алерты и понятные инструкции "что делать, если упало"
• учет ресурсов раннеров и план роста (CPU, RAM, диск)

Производительность и масштабирование CI: раннеры и ресурсы

Главный вопрос по производительности CI простой: где физически будут крутиться сборки. В GitLab CE это чаще GitLab Runner на отдельной ВМ или на железе, а в связке Gitea + Drone - Drone Runner (Docker или Kubernetes). Логика одна: чем меньше CI мешает самому Git-сервису, тем стабильнее все работает.

Хорошая практика для любого варианта - выносить выполнение джобов на отдельные раннеры. Так вы не ловите ситуацию, когда тяжелая сборка забивает диск или CPU, и вместе с ней "подвисают" push/pull, веб-интерфейс и API.

Емкость CI обычно упирается в параллельность: сколько джобов может идти одновременно и как быстро освобождаются слоты. Если вы видите очереди, сначала проверьте лимиты (concurrency) и количество раннеров, и только потом добавляйте мощность.

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

Типичные узкие места, которые проявляются раньше, чем CPU:

• диск (много мелких файлов, распаковки, Docker layers)
• сеть (скачивание пакетов, образы, доступ к внешним репо)
• база и файловое хранилище самого сервиса (если CI и Git живут на одной машине)
• container registry (если вы активно собираете и пушите образы)

Быстрый способ прикинуть ресурсы

Без сложных расчетов можно стартовать так: возьмите пиковый час и посчитайте, сколько сборок реально нужно параллельно. Например, команда из 12 человек делает 20-30 запусков в час, средняя сборка 10 минут. Значит комфортно иметь 4-6 параллельных слотов, чтобы не копить очередь.

Дальше масштабируйтесь добавлением раннеров, а не "укрупнением" одного. Если вы и так размещаете инфраструктуру на своих серверах (например, на стойке в дата-центре), проще докупить еще один узел под раннеры, чем постоянно бороться за ресурсы на единственной машине. Это особенно важно, если CI/CD на open source разворачивается внутри контура с повышенными требованиями к изоляции.

Что можно перенести без потерь, а что потребует отдельного плана

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

К тому, что "живет внутри Git" и переносится надежно, относятся: коммиты и вся история, ветки, теги, сабмодули (как ссылки), а также файлы конфигурации CI (например, .gitlab-ci.yml или .drone.yml). Это обычные файлы в репозитории, и их важно сохранить в первую очередь.

А вот многое, к чему команда привыкает каждый день, Git не хранит. Это данные платформы и интеграций, и для них нужен отдельный план переноса или осознанное решение "оставляем как есть":

• Issues, merge requests, ревью и комментарии
• Wiki (часто отдельный репозиторий, но переносится отдельно)
• история пайплайнов, логи запусков, статусы проверок
• секреты, переменные, защищенные ветки, права доступа, webhooks
• релизные артефакты: пакеты, образы, вложения к релизам

Правило номер один: сначала пробная миграция на тестовом проекте. Возьмите репозиторий среднего размера, прогоните типичный пайплайн и проверьте: совпадает ли количество веток и тегов, открывается ли нужный тег релиза, подтянулись ли LFS-объекты, стартуют ли сборки.

План отката должен быть простым. На время миграции заморозьте записи в старом репозитории, после переключения оставьте его в режиме только чтение на оговоренный срок и держите быстрый путь назад: вернуть доступ к старой системе и повторить перенос после исправлений.

Пошагово: перенос репозиториев с сохранением всей истории

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

Сначала сделайте инвентаризацию: список репозиториев, активных веток, тегов, включен ли Git LFS, какие есть вебхуки, кто владелец и какие группы имеют доступ. Полезно сразу выписать, какие интеграции важны для CI/CD на open source: уведомления, зеркалирование, секреты, триггеры пайплайнов.

Дальше согласуйте окно переноса и заморозку изменений. На время миграции запретите push (или переведите репозиторий в read-only), чтобы не ловить коммиты, которые появились в последний момент.

Команды для переноса Git-истории

Самый надежный способ сохранить всю историю, включая все refs, это зеркальная миграция:

# на старом хостинге
git clone --mirror <OLD_REPO_URL>
cd <repo>.git

# на новом хостинге
git remote set-url --push origin <NEW_REPO_URL>
git push --mirror

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

Если используется Git LFS, его нужно перенести отдельно: убедитесь, что LFS включен на новом сервере, затем выполните перенос LFS-объектов и проверьте несколько крупных файлов (скачивание и сборка).

Быстрая проверка после переноса

Завершите перенос короткой проверкой, прежде чем снимать заморозку:

• Сравните количество веток и тегов, убедитесь, что нет пропавших release-тегов.
• Сверьте число коммитов (хотя бы по главной ветке) и общий размер репозитория.
• Проверьте LFS: один-два файла должны скачиваться без ошибок.
• Восстановите доступы: владельцы, группы, права на push, protected-ветки.
• Обновите вебхуки и запустите тестовый пайплайн, чтобы убедиться, что триггеры и секреты настроены правильно.

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

Частые ошибки при выборе и миграции

Самая неприятная ошибка - выбрать платформу "по привычке", а потом месяцами закрывать пробелы в доступах, аудитах и интеграциях. CI/CD на open source работает стабильно, когда заранее договорились о правилах и границах ответственности.

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

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

• Переносят Git-историю, но забывают про Git LFS: в результате большие файлы подменяются указателями, а сборка или тесты падают из-за "пустых" артефактов.
• Меняют CI-систему и переиспользуют старые секреты как есть: токены и ключи оказываются не теми, права отличаются, деплой начинает давать 401/403 или выкатывает не туда.
• Запускают раннер в общей сети "как удобно": у него появляется лишний доступ к внутренним сервисам и секретам, и любая уязвимость в пайплайне превращается в риск для всей инфраструктуры.
• Считают, что правила ревью и защиты веток "само собой" перенесутся: после миграции люди пушат прямо в main, а качество падает, потому что нет обязательных проверок и код-ревью.

Как поймать проблемы до запуска

Полезно относиться к миграции как к короткому проекту с приемкой, а не как к копированию репозитория. Хороший ориентир - подготовить контрольный прогон на одном типовом сервисе и довести его до стабильного деплоя.

• До первого релиза проверьте восстановление из бэкапа: не только сам Git, но и конфиги CI, секреты, переменные окружения, права доступа.
• Зафиксируйте модель доступов: кто может создавать раннеры, кто видит логи, кто управляет секретами, и где хранится аудит.
• Сделайте отдельную проверку окружений: раннеру нужен минимум сети и минимум прав, особенно в гос, фин и мед организациях.

Если эти пункты закрыты заранее, миграция проходит спокойнее, а "неожиданности" остаются в тестовой зоне, а не в проде.

Чеклист, пример и следующие шаги

Если свести выбор CI/CD на open source к практике, важнее всего не "что популярнее", а что вы сможете поддерживать каждый день без сюрпризов для безопасности и команды.

Короткий чеклист выбора

Перед тем как спорить про функции, ответьте на несколько вопросов и зафиксируйте их письменно:

• команда и проекты: сколько разработчиков, сколько репозиториев, как часто релизы и сколько параллельных пайплайнов
• ИБ и комплаенс: кто и как выдает доступы, нужен ли аудит действий, требования к хранению секретов, изоляция раннеров
• интеграции: какие реально нужны (трекер задач, реестр образов, сканирование, уведомления), а какие "когда-нибудь"
• эксплуатация: кто обновляет, делает бэкапы, мониторит, восстанавливает после сбоя, и сколько времени на это есть
• бюджет времени: сколько недель вы готовы потратить на внедрение и сколько часов в неделю на поддержку

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

Короткий чеклист миграции

Чтобы перенос прошел без паники, держите простой план:

• тест: прогон миграции на одном неключевом репозитории и проверка сборок
• окно: согласованное время, когда изменения в старом репо ограничены
• перенос: зеркальный push/импорт, затем перенос настроек CI и секретов по новой схеме
• проверка: история коммитов, теги, ветки, права, статусы сборок, ключевые пайплайны
• откат: четкое условие "стоп" и план возврата на старую систему

Пример сценария: 30 разработчиков, несколько сред (dev, stage, prod), часть сервисов критична, нужен on-prem и аудит. Часто выигрывает более цельный вариант, где проще закрыть требования по правам и журналам действий, а раннеры изолировать по средам. Если же важна модульность и вы хотите отдельно контролировать компоненты, связка из нескольких инструментов может быть удобнее, но потребует дисциплины в поддержке и обновлениях.

Следующий шаг - выбрать один типовой проект и провести пилот на 1-2 недели: измерить время сборок, стабильность раннеров и нагрузку на админов. Параллельно оцените инфраструктуру под CI (CPU, RAM, диски, резервирование).

Если внутри команды нет времени на развертывание и поддержку, имеет смысл подключать интегратора. Например, GSE.kz (gse.kz) как производитель и системный интегратор в Казахстане может помочь с on-prem инфраструктурой, включая серверы S200, и с организацией поддержки, когда критичны ИБ и непрерывность.