GitOps-пайплайн деплоя: от PR до production без боли

Основной стек деплоя выглядит так:

Для рискованных или ранних фич мы также используем фича-флаги (feature flags) через PostHog, но это отдельная тема — поговорим о ней в следующих статьях.

Изменения кода сначала попадают в staging, мы тестируем и прогоняем регрессию внутри команды, а затем продвигаем в production в часы минимальной нагрузки.

Разберём по шагам — что именно происходит и зачем.

Обычно работу над фичей А мы начинаем от main (иногда от staging, в зависимости от темпа) и ведём разработку в отдельной ветке.

Ветки фич нужны нам не ради «идеальной изоляции», а как удобная единица для:

Когда фича готова, открываем PR и проводим командное ревью.

Этот этап недооценивают. Именно здесь удаётся поймать много рисков на ранней стадии:

Мы не воспринимаем PR как бюрократию. Для нас это последний спокойный момент перед тем, как изменение попадает в общую среду.

это мы, когда кто-то рефакторит 💀

После прохождения PR делаем merge в staging.

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

Если что-то сломается в Kubernetes, пусть это произойдёт в staging — именно для этого он и нужен.

Как только код попадает в staging, GitHub Actions берёт на себя рутину, которую человек делать не должен:

В этом и заключается прелесть доставки на основе контейнеров: мы деплоим артефакты, а не «что случайно оказалось на виртуальной машине».

У нас есть отдельный репозиторий для деплоев — внутри команды мы называем его openmirai deploy.

В нём хранятся Kubernetes-манифесты (или конфиги kustomize/helm), и именно он является источником истины о том, что запущено в каждом окружении.

Ключевой момент:

Наш GitHub Action обновляет конфигурацию деплоя, записывая новый SHA образа в соответствующий файл Kubernetes deployment.

То есть вместо того, чтобы «толкать» деплои, мы фиксируем желаемое состояние в виде коммита.

Это даёт нам:

Это также означает, что для staging Argo CD не требует особого вмешательства человека.

Argo CD непрерывно следит за репозиторием деплоев.

Обнаружив изменение — например, новый SHA образа — он приводит кластер в соответствие с ним.

Поток выглядит так:

git commit → синхронизация Argo CD → пересоздание подов → staging обновлён

Именно в этом нам нравится GitOps: деплои превращаются в контролируемое, проверяемое изменение репозитория, а не в ручной ритуал.

После того как новая версия запущена в staging, мы проводим внутреннее тестирование:

Если уверенности нет — не продвигаем. Чиним и повторяем.

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

Когда staging выглядит хорошо, делаем merge в main.

Это наш шаг «продвижения кодовой базы».

Мы убедились: если относиться к main как к «тому, что мы считаем готовым к production», это держит команду в одном понимании ситуации. Кроме того, это делает хотфиксы и откаты менее хаотичными.

Деплои в production мы проводим в часы минимальной нагрузки — как правило, с 23:00 до 01:00.

Отчасти это снижает влияние на пользователей, но главное — даёт нам спокойное окно для наблюдения за релизом.

Да, автоматический непрерывный деплой — это круто. Но командам на ранних этапах не всегда нужно «деплоить когда угодно». Иногда им нужно «деплоить безопасно».

Поэтому мы предпочитаем осознанные выпуски в production в предсказуемое время.

После деплоя в production мы выполняем постпроверки:

Это скучно, и именно поэтому работает.

Несколько принципов, на которые мы ориентируемся:

Даже «скучные» пайплайны развиваются. Вот над чем мы активно думаем:

И да, фича-флаги заслуживают отдельной статьи — особенно то, как мы используем PostHog, чтобы снижать риски и при этом выпускать фичи раньше.

Пайплайн деплоя — это не просто DevOps-диаграмма. Это продуктовое решение.

Для нас связка GitHub Actions + GHCR + единый репозиторий деплоев + Argo CD даёт понятный, ненервный путь от push до production — без превращения деплоев в «героический подвиг».

Если вы строите мультитенантный продукт, где важна надёжность, настоятельно рекомендую держать свой пайплайн скучным.