GitFlic как замена GitLab: тестируем корпоративную версию на реальном проекте КИИ

Несколько дней назад GitFlic объявил корпоративную версию с встроенным CI/CD. Для нас это не просто новость - у нас как раз живёт клиент с требованием хранить исходный код и IaC-конфиги в системах, включённых в реестр отечественного ПО. GitLab - под вопросом, GitHub - точно нет. GitFlic в реестре есть, и корпоративная версия с пайплайнами означает, что можно наконец потестировать его как полноценную замену, а не просто хранилище репозиториев.

Несколько дней тестирования - делимся тем, что заметили.

Контекст: зачем вообще

Клиент - объект КИИ второй категории. Требование хранить исходный код в отечественных системах пришло от службы безопасности после мартовских событий - не как регуляторная обязанность, а как внутренняя политика. До этого работали на самохостинге GitLab CE, и всех устраивало.

Самохостинг GitLab формально возможен и дальше - лицензия Community Edition открытая. Но вопрос стоит иначе: клиент хочет зависеть от вендора, у которого есть российское юрлицо, российская поддержка и запись в реестре Минцифры. GitLab этому не соответствует. GitFlic - соответствует.

Задача для нас: аудит того, насколько GitFlic закрывает текущий рабочий процесс - Terraform, Ansible, Docker-образы, простые CI-пайплайны. Не migration guide, а честная оценка готовности.

Что попробовали

Развернули GitFlic Enterprise на отдельной виртуалке под РЕД ОС 7.3. Установка через RPM-пакет - без сюрпризов, всё встаёт штатно. Системные требования скромнее GitLab: 4 CPU и 8 GB RAM для нашего размера - хватает.

Перенесли несколько репозиториев через git remote - обычный push в новый remote. Базовая работа с репозиториями работает как ожидается: ветки, теги, merge request-ы. Интерфейс явно вдохновлён GitLab, навигация понятная. Для разработчиков, пересевших с GitLab, порог входа минимальный.

CI/CD - это то, ради чего вообще стоит разбираться с корпоративной версией. Синтаксис конфигурации пайплайнов похож на GitLab CI, хотя не идентичен. Простой пайплайн вида «запустить линтер, собрать образ, отправить в registry» заработал после небольшой правки .gitflic-ci.yml. Что конкретно пришлось поменять:

• Синтаксис image - GitFlic использует немного другой формат указания Docker-образа раннера.
• Переменные окружения - часть предопределённых переменных GitLab (типа $CI_COMMIT_REF_NAME) называются иначе, список предопределённых короче.
• artifacts - базовые артефакты работают, но expire_in не поддерживается в текущей версии.

Terraform-пайплайны потребовали чуть больше времени. Основная проблема - не синтаксис CI, а кеширование провайдеров. В GitLab мы кешировали .terraform-директорию между джобами через cache:. В GitFlic cache-механизм есть, но работает иначе: кеш привязан к ветке жёстче, и между разными ветками при pull request он не шарится так, как мы привыкли. Обошли через явное скачивание провайдеров на каждом запуске - некрасиво, но работает. В изолированной среде клиента с внутренним Nexus это всё равно быстро.

Что не хватает

Честно - есть пробелы, которые для нас сейчас важны.

Environments и deployment tracking - в GitLab у нас настроены environments для staging и production, с историей деплоев, ссылками на конкретные коммиты и возможностью rollback через UI. В GitFlic этого нет. Не «работает иначе», а именно нет.

Protected branches с детальными правилами - есть базовая защита, но без гибкости GitLab. Например, нельзя разрешить push в main только через MR с минимумом одного апрувала от определённой группы. У клиента это важно: несколько команд, у каждой своя зона ответственности в репозитории.

API - есть, но покрытие существенно меньше GitLab API. Часть наших внутренних скриптов для автоматизации (проверка статуса пайплайнов, создание MR-ов) придётся переписать или упростить.

Container Registry - есть встроенный, и это хорошо. Но совместимость с клиентскими инструментами пришлось проверять вручную: Kaniko и Buildah работают, стандартный Docker daemon тоже.

Общее ощущение

GitFlic - рабочая платформа для хранения кода и несложных пайплайнов. Если задача стоит «перестать зависеть от зарубежного хостинга и иметь что-то понятное для разработчиков» - он закрывает её достаточно. Для команд, которые используют GitLab как простой Git-хостинг с базовыми CI-пайплайнами, переход будет безболезненным.

Для нашего клиента картина сложнее. Текущий процесс с Terraform, несколькими командами и тонкой настройкой прав требует либо упрощения процесса, либо компенсации отсутствующих фич внешними инструментами - что добавляет сложность там, где её не хотелось бы. Мы не готовы сказать «переходите» прямо сейчас.

Но и «не трогайте» тоже не скажем. Продолжаем смотреть - корпоративная версия только вышла, и судить о платформе по первой неделе некорректно. Следующий шаг - погонять несколько реальных спринтов на GitFlic параллельно с текущим GitLab, посмотреть на реальное трение в ежедневной работе.