От git push до production — без страха

1. Подключите репозиторий один раз — конвейер появится сам

Пример приложения — небольшое веб-приложение семейного дерева (сервис Node за контейнером). Вся настройка сводится к подключению его репозитория GitHub:

• На Platforms → Container Apps подключите GitHub и выберите репозиторий и ветку (main).
• Это превращает приложение в Deployment pipeline: окружение Staging (тестовая копия на собственном URL ca-*.cdn.com.tr) и Production, а между ними кнопка Promote.
• С этого момента каждый push автоматически деплоится в Staging — пушем кода вы никогда не трогаете production.

2. Каждый push попадает в Staging — production продолжает обслуживать трафик

Вот одно и то же приложение в обоих окружениях в один и тот же момент. Обратите внимание на метку сборки в футере: у Staging уже новая сборка из последнего push, а Production всё ещё обслуживает предыдущую. В production-приложении ничего не пересобиралось, поэтому пока компилировалась новая сборка, не было ни простоя, ни 504.

• Staging автоматически собрал и задеплоил последний коммит — доступен на собственном тестовом URL.
• Production не тронут: та же работающая сборка, тот же боевой домен, без перерывов.
• Вы тестируете новую сборку в реальном изолированном окружении до того, как её увидит хоть один пользователь production.

3. Проверьте на реальном URL Staging

Staging — это по-настоящему работающая копия приложения на собственном субдомене — тот же образ, те же аддоны — так что вы кликаете по настоящему изменению, а не по макету. Двигаетесь дальше, только когда всё в порядке.

• Откройте тестовый URL Staging с карточки конвейера и проверьте изменение целиком.
• Что-то сломали? Просто запушьте исправление — Staging передеплоится, Production по-прежнему в безопасности.

4. Promote: один клик, без пересборки

Promote ничего не собирает. Он переключает origin production-домена на уже работающую сборку Staging — мгновенное, атомарное переключение. Сборка, которую вы тестировали, побайтово совпадает со сборкой, которая выходит в прод.

• Нажмите Promote на карточке конвейера — production теперь обслуживает именно ту сборку, которую вы проверили в Staging.
• Поскольку это переключение domain-origin (а не пересборка), переход происходит мгновенно и без простоя.
• Rollback работает так же, только в обратную сторону: один клик возвращает production к предыдущей сборке (со снимком БД, если он есть у приложения).

Тот же конвейер из терминала (cdnctl)

Всё вышеперечисленное можно автоматизировать скриптами — удобно для CI. Панель и cdnctl используют одни и те же эндпоинты:

# Connect once in the panel, then every push to main auto-deploys to Staging.
# Verify Staging on its test URL, then promote the tested build to production:
cdnctl container apps status  --account <uuid> --app <staging_app_uuid>
cdnctl container apps promote --account <uuid> --app <staging_app_uuid>

# Roll back to the previous production build if needed (instant, no rebuild):
cdnctl container apps rollback-promotion --account <uuid> --app <prod_app_uuid>

Почему это безопасно по конструкции

• Push кода никогда не может сломать production — авто-деплой нацелен только на Staging.
• То, что вы промоутите, — это в точности то, что вы тестировали (между тестом и продом нет пересборки).
• Переход и rollback — это мгновенные переключения domain-origin, а не медленные передеплои.
• Сборки происходят в стороне, поэтому боевой сайт никогда не возвращает 504 во время компиляции.

Справочные руководства: Deployment pipeline · Deploy from Git · Blue/green окружения.