GitOps без боли: Continuous Promotion в Kubernetes 🚀

Одна из самых сложных частей CI/CD в Kubernetes - это promotion между окружениями:
dev → stage → prod.

Все умеют “задеплоить в dev”, но дальше начинается хаос:
- кто и когда двигает релиз в staging?
- как не сломать прод?
- как избежать ручных кнопок и «перекинь тег в чате»?

Решение - Continuous Promotion по GitOps.

Что это значит
Promotion - это не “новый деплой”, а перевод уже собранного релиза на следующий этап.

И в GitOps это делается правильно:
✅ *Git = единственный источник правды*
✅ каждый переход окружения - это коммит/PR
✅ Argo CD (или Flux) просто синхронизирует кластер с репо
✅ релиз продвигается автоматически, когда проходят проверки

Как выглядит пайплайн
1) CI собирает образ и пушит в registry
2) Обновляется манифест (tag/digest) в репозитории окружения dev
3) После тестов создаётся PR на stage
4) После approval/валидаторов PR мерджится
5) Argo CD подтягивает изменения → stage обновлён
6) То же самое для prod

Какие инструменты обычно используют
- Argo CD - синхронизация состояния кластера с Git
- Kargo (Akuity) - управление promotion (когда/как переводить релиз)
- Helm/Kustomize - упаковка релизов под окружения

Почему это топ-подход
🔥 нет ручных “перекинь версию”
🔥 история релизов всегда в Git
🔥 откаты = обычный revert
🔥 можно встроить правила: security checks, e2e, approvals
🔥 идеально для больших команд и микросервисов

Вывод
Если ты хочешь настоящий production GitOps, то деплой - это только половина.
Вторая половина - promotion между окружениями, и она должна быть:
- декларативной
- автоматизированной
- и воспроизводимой через Git.

Это тот случай, когда GitOps реально превращается в систему, а не в модное слово.

https://piotrminkowski.com/2025/01/14/continuous-promotion-on-kubernetes-with-gitops/