Переход на GitOps часто ломает привычный CI/CD. Пайплайн зелёный, образы собраны, но в кластер уезжает не то, что ожидалось. Причина в том, что CI и CD начинают жить отдельно: CI отвечает за сборку и тесты, а CD — за синхронизацию состояния из Git. В такой схеме классический «проталкивающий» пайплайн, который сам деплоит, перестаёт быть единственным источником истины. Возникает разрыв: как обновлять манифесты с новым тегом образа, кто и когда это делает, как откатывать. В статье разберём, как выстроить промоушен — управляемое продвижение образа по средам — и какие инструменты для этого использовать.

Почему CI/CD «ломается» в GitOps

В традиционном подходе CI-система после сборки сама вызывает деплой: применяет манифесты или дергает API кластера. В GitOps деплой выполняет оператор (Argo CD, Flux), который следит за Git-репозиторием. CI больше не может «пушить» — он должен «пулить» изменения в Git. Если продолжать деплоить из CI, вы обходите GitOps и теряете его преимущества: аудит, откат, дрейф-детекцию. Кроме того, разные среды (dev, stage, prod) часто находятся в разных репозиториях или ветках, и обновлять их вручную — путь к ошибкам.

Типичная картина: в CI-скрипте появляются костыли — sed для замены тега в YAML, отдельные хуки, которые коммитят изменения в другой репозиторий. Это работает, но хрупко: легко забыть обновить нужную среду, получить конфликт или сломать форматирование. Чем больше сред и команд, тем острее потребность в едином конвейере промоушена.

Простые решения: когда хватит скриптов и sed

Если у вас одна команда, две-три среды и нет жёстких требований к аудиту, можно начать с минимальной автоматизации. Суть: CI после сборки образа обновляет тег в Git-репозитории с манифестами. Например, с помощью sed или yq меняет значение image в values.yaml или kustomization.yaml и делает коммит. Затем GitOps-оператор подхватывает изменение.

Чтобы это было надёжно, следуйте шагам:

  • Выделите отдельный репозиторий (или директорию) для конфигурации сред. CI не должен напрямую менять прод — только создавать коммит или пулл-реквест.
  • Используйте шаблонизацию (Helm, Kustomize), чтобы тег образа был параметром, а не жёстко прописанным значением.
  • Настройте проверку: перед коммитом валидируйте YAML и убедитесь, что изменён только нужный параметр.
  • Добавьте защиту веток: изменения в прод-среду — только через merge request с ревью.

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

Специализированные инструменты: от Argo CD до Kargo

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

  • Встроенные возможности GitOps-операторов. Argo CD поддерживает ApplicationSet и генераторы, Flux — Kustomization с зависимостями. Они позволяют автоматизировать обновление тегов, но логику промоушена (например, «сначала stage, потом prod») приходится описывать самостоятельно.
  • CI-ориентированные подходы. Обновление тега через пайплайн с использованием API Git-провайдера (GitHub, GitLab). Гибко, но требует поддержки скриптов и не даёт готового UI для отслеживания состояния промоушена.
  • Специализированные платформы. Например, Kargo (от создателей Argo CD) или аналоги. Они вводят понятия Stage, Freight, Promotion и предоставляют декларативное описание процесса: какой образ в какой среде, какие проверки пройти, как откатить. Это снижает количество самописных скриптов и даёт единую точку контроля.

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

Критерии выбора и типичные ошибки

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

  • Количество сред и команд. Чем больше, тем выше потребность в централизованном управлении.
  • Требования к аудиту и безопасности. Нужен ли полный след кто и когда продвинул образ, есть ли разделение ролей.
  • Сложность логики. Нужны ли автоматические проверки (тесты, сканирование уязвимостей) перед переходом на следующую среду.
  • Ресурсы на поддержку. Готовы ли вы поддерживать самописные скрипты или лучше взять готовый инструмент.

Типичные ошибки, которые встречаются при настройке промоушена:

  • Прямой деплой из CI в обход GitOps. Приводит к рассинхронизации состояния и потере преимуществ GitOps.
  • Изменение манифестов вручную. Рано или поздно кто-то забудет обновить тег или ошибётся в среде.
  • Отсутствие валидации. Сломанный YAML или неверный тег может уехать в прод.
  • Игнорирование отката. Процесс промоушена должен включать возможность быстро вернуть предыдущую версию.

Например, команда использовала sed для замены тега в манифестах. В один момент в values.yaml было два вхождения image, и скрипт заменил оба, включая sidecar-контейнер. В итоге в прод уехал несовместимый сайдкар. Подобных ошибок можно избежать, если использовать шаблонизацию и точечные обновления через API инструмента.

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