GitFlic CI/CD в госсекторе: первый реальный пайплайн на отечественной платформе

Один из клиентов - субъект КИИ из госсектора - уже несколько месяцев переезжает с GitLab на GitFlic. Репозитории перенесли раньше, это несложно. Застряли на CI/CD: хотелось не просто хранить код в отечественной платформе, но и гонять там пайплайны. Наконец собрали первый рабочий вариант - и есть что рассказать.

Почему GitFlic, а не что-то другое

Выбор был не случайным. На рынке отечественных git-хостингов с претензией на enterprise GitFlic - наиболее зрелый вариант; остальные решения либо являются иностранными продуктами (GitLab, Bitbucket), либо представляют собой self-hosted Gitea/Forgejo без отечественной сертификации. GitFlic - единственный, кто изначально разрабатывался именно как замена GitLab, а не как форк чужого кода с локализацией. Есть сертификаты ФСТЭК, есть поддержка работы в изолированном контуре. Для организации с требованиями по КИИ это важнее, чем богатство функциональности на старте.

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

Что пришлось настраивать

GitFlic CI появился относительно недавно. Синтаксис конфигурационного файла похож на GitLab CI, но не идентичен - это важно, потому что прямая миграция .gitlab-ci.yml не работает. Пришлось переписывать.

Основной пайплайн у клиента несложный: сборка Java-приложения через Maven, прогон unit-тестов, публикация артефакта во внутренний Nexus, деплой в тестовую среду через SSH. Всего четыре стадии, ничего экзотического.

Вот с чем столкнулись при настройке:

• Раннеры. GitFlic использует собственный агент, не совместимый с GitLab Runner. Устанавливается отдельно, документация есть, но местами куцая. Пришлось поднять два раннера: один для сборки, второй для деплоя - они работают в разных сетевых сегментах, и маршрутизации между ними нет.
• Кэширование зависимостей. В GitLab это решается двумя строчками. В GitFlic механика кэша реализована, но поведение в отдельных кейсах расходится с документацией. Несколько часов ушло на то, чтобы кэш Maven не сбрасывался при каждом запуске.
• Переменные окружения и секреты. Хранилище секретов есть, интерфейс рабочий. Одна особенность: переменные с одинаковыми именами на уровне проекта и группы обрабатываются иначе, чем в GitLab - группа не перекрывает проект, а дополняет. Это не баг, это документированное поведение, просто непривычно.
• Условия запуска. only/except работают, rules в том виде, к которому привыкла команда по GitLab, не все поддерживаются. Несколько условий пришлось переформулировать проще.

Что получилось

Пайплайн работает. Сборка, тесты, деплой в тест - всё едет. Время выполнения сопоставимо с тем, что было на GitLab, потому что узкое место - Maven с его зависимостями, а не платформа.

Команда разработки поворчала неделю про «всё не так, как привыкли» и успокоилась. Критических блокеров не обнаружили. Из неудобств, которые остались:

• Нет merge request pipelines в том виде, в каком они работают в GitLab (запуск пайплайна при открытии MR с видимостью статуса прямо в интерфейсе MR). Обошли через триггеры по веткам, но это хуже.
• Уведомления. Интеграция с корпоративной почтой настроилась, а вот Mattermost пришлось подключать через webhook вручную - готового плагина нет.
• Матрицы сборок не поддерживаются. Для данного проекта не нужны, но в других может быть проблемой.

Честная оценка

GitFlic CI - это не GitLab CI. Разрыв в функциональности реальный, и его не стоит замалчивать. Для простых линейных пайплайнов сборки-тестирования-деплоя платформа справляется. Для сложных сценариев с динамическими дочерними пайплайнами, матрицами, тонкой настройкой условий - придётся либо упрощать, либо страдать.

В госсекторном контексте это часто приемлемо: реальные пайплайны там, как правило, проще, чем у продуктовых команд. Требование «всё в российском периметре, всё сертифицировано» важнее, чем наличие триста первой фичи в CI.

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

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