CONTAINER APPS · РУКОВОДСТВО

Deployment pipeline: push → Staging, Promote → Production

Подключите Git-репозиторий один раз, и каждый push будет деплоить копию вашего приложения в Staging — push никогда не затрагивает production. Вы тестируете новую сборку на собственном URL Staging, затем нажимаете Promote, чтобы вывести в прод именно эту протестированную версию. Если что-то не так, Roll back восстанавливает предыдущую версию (включая снимок базы данных) одним кликом. Больше никаких простоев из-за «каждый коммит передеплоивает production».

← Все руководства по платформе

Что вам нужно

Compose-проект, уже развёрнутый через Deploy from Git с включённым «Keep connected — auto-deploy on every push». Это всё, что требуется: карточка конвейера появляется автоматически на Platforms → Container Apps для каждого подключённого репозитория.

Конвейер в двух словах

git push ──▶ [ STAGING ]  ──  Promote ──▶ [ PRODUCTION ]
              передеплой              вручную; выводит
              на каждый push          протестированную сборку в прод

Staging — это реальная, отдельная копия вашего приложения с собственным тестовым URL <uid>.cdn.com.tr — обслуживается через CDN edge точно так же, как production.
Production продолжает обслуживать старую версию нетронутой, пока Staging собирается и деплоится. Он меняется только когда вы нажимаете Promote.
Roll back всегда доступен после Promote — восстанавливаются трафик/образ и снимок базы данных, сделанный перед promote.

Карточка Deployment pipeline: сверху репозиторий и ветка; колонка Staging, автоматически деплоящаяся со своим тестовым URL; кнопка Promote; и колонка Production с боевым URL — Карточка Deployment pipeline на Platforms → Container Apps. Слева: Staging (авто-деплой, тестовый URL). Справа: Production (боевой URL). Между ними: Promote.

1 · Подключите репозиторий (один раз)

В Platforms → Container Apps → App creation → Deploy from Git подключите GitHub (рекомендуется — GitHub App в один клик, без токенов для управления) или используйте URL репозитория + токен доступа, выберите репозиторий и ветку, отметьте «Keep connected — auto-deploy on every push to this branch», затем Build & deploy. Подробности: руководство Deploy from Git.

Панель Deploy from Git с подключённым GitHub, выбором репозитория, веткой и флажком keep-connected auto-deploy — Подключите GitHub и держите репозиторий подключённым — именно это создаёт конвейер.

2 · Включите Staging

На карточке конвейера нажмите Enable staging. Это создаёт тестовую копию каждого приложения репозитория и направляет на неё авто-деплой — с этого момента push деплоит Staging, никогда не Production.

Тестовая копия автоматически получает собственный публичный тестовый URL (<uid>.cdn.com.tr). Если у ранее созданной копии ещё нет URL, на карточке появляется кнопка Get test URL.
Data sharing (в разделе «Data sharing options», по умолчанию shared): shared — Staging использует ту же базу данных/Redis/хранилище, что и production (лучше всего для изменений кода/UI); cloned — Staging получает собственный MySQL с копией данных (безопасно для изменений схемы); isolated — чистый старт.
При первом открытии свежего тестового URL возможен кратковременный ответ 502, пока активируются edge/DNS (~минута) — это нормально и происходит один раз.

Карточка конвейера до появления staging: кнопка Enable staging в колонке Staging с параметрами разделения данных под ней — Первый запуск: Enable staging создаёт тестовую копию и перенаправляет на неё авто-деплой.

3 · Push — Staging деплоится сам

Каждый push в подключённую ветку собирает образ и раскатывает его в Staging. Карточка показывает последний push (коммит + время) и статус Staging в реальном времени.
Откройте Test URL и проверьте новую сборку — production всё ещё обслуживает предыдущую версию, совершенно не затронутую.
Пока Staging раскатывается, его статус показывает deploying; Promote остаётся неактивным, пока копия не заработает.

4 · Promote — выведите протестированную версию в прод

Нажмите Promote. Production немедленно начинает обслуживать протестированную версию — без сборки и без простоя. Сначала делается автоматический снимок базы данных, так что rollback сможет откатить и изменения данных. Под капотом используется один из двух механизмов:

Подключён ваш собственный домен → мгновенное переключение origin на CDN edge: боевой домен сначала подключается к staging-приложению, затем отвязывается от старого — чистый перенос трафика, секунды, без перезапуска.
Production на своём субдомене <uid>.cdn.com.tr → уже собранный, уже протестированный образ раскатывается на production-приложение через rolling-обновление без разрыва (старый под продолжает обслуживать, пока новый не готов). URL остаются стабильными: тестовый URL всегда у Staging, боевой URL всегда у Production.

Promote переносит сборку, а не конфигурацию: переменные окружения и секреты, заданные в Staging, остаются в Staging. Меняйте конфигурацию production в production-приложении.

Карточка конвейера с работающей сборкой Staging и активной кнопкой Promote — Staging работает и проверен — Promote выводит в прод именно эту сборку.

5 · Roll back (если понадобится)

После Promote на стороне Production появляется кнопка Roll back. Один клик восстанавливает предыдущую версию — переключение домена отменяется (или заново деплоится предыдущий образ), а снимок базы данных, сделанный перед promote, восстанавливается.
Rollback — такая же мгновенная операция без пересборки, как и Promote.

Полезно знать

Отключение конвейера: «Disable staging» на карточке снова заставляет push деплоить production напрямую (старое поведение — может вызывать простой во время деплоя). Тестовая копия сохраняется.
Новые сервисы: авто-деплой обновляет существующие сервисы; сервис, недавно добавленный в compose-файл, не добавляется автоматически — чтобы добавить его, один раз запустите Deploy from Git.
Проекты с несколькими приложениями: Enable staging создаёт тестовую копию для каждого сервиса репозитория, а «Promote all» выводит весь набор в прод одновременно.
Ручные тестовые копии: приложения, не подключённые к репозиторию, всё равно могут использовать те же механизмы staging/promote из панели окружений — см. руководство Blue/green environments и практический пример.
CLI: те же операции доступны через cdnctl.