Деплой из Git: пушите в свою ветку — новая версия уходит в продакшен

Что на самом деле означает «деплой из Git»

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

Деплой через git заменяет эту последовательность правилом: ветка — источник истины, и то, что на ней лежит, то и работает. Вы ничего не загружаете. Вы пушите, а платформа каждый раз выполняет одну и ту же сборку. Смысл именно в повторяемости, а не в удобстве.

Что происходит между вашим push и живым приложением

Цепочка короткая, и её стоит знать: когда что-то идёт не так, вам нужно понимать, на какое звено смотреть.

Ваш push доходит до репозитория, и тот уведомляет нас. Мы проверяем, подключены ли к приложению именно этот репозиторий и эта ветка; если да — стартует сборка. Сборка выполняется в изолированной песочнице — ваш код никогда не делит процесс с чужим — и создаёт контейнерный образ из вашего Dockerfile. Только когда образ готов, платформа запускает новую версию и выводит из работы старую. Если сборка падает, ничего не заменяется: предыдущая версия продолжает обслуживать трафик — именно то поведение, которого вы хотите в два часа ночи.

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

Что нужно вашему репозиторию

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

Больше всего времени людям экономят две детали. Первая: ваше приложение должно слушать тот порт, о котором вы сообщили платформе, и на всех интерфейсах (`0.0.0.0`), а не только на `localhost` — контейнер, привязанный к localhost, недостижим снаружи самого себя. Вторая: всё секретное (строки подключения к базе, API-ключи) место в переменных окружения, а не в образе: образы пересобираются и переезжают, а секрет, запечённый в образ, — это секрет, который вы не сможете ротировать.

Многосервисный проект работает так же через Compose-файл: каждому сервису без готового образа нужен собираемый Dockerfile, и стек поднимается уже связанным.

Ветки: держите продакшен в стороне от повседневной работы

Именно здесь команды обжигаются, и лечится это решением, а не функцией. Если продакшен подключён к ветке, в которой вы разрабатываете, в продакшен уезжает каждый наполовину готовый commit. Подключайте продакшен к ветке, в которую вы вливаете изменения только осознанно, — обычно это `main`, пока повседневная работа идёт в feature-ветках, либо отдельная ветка `production`, если `main` — это место, где вы итерируете.

Полезная мысленная проверка: «если я запушу прямо сейчас, меня устроит, что это увидят посетители?» Если для подключённой ветки ответ хоть раз «нет», значит неправильна ветка, а не процесс.

Релизный поток, при котором продакшен остаётся скучным

# gundelik is: feature dalinda
git checkout -b feature/yeni-fiyatlandirma
git commit -am "pricing page"
git push origin feature/yeni-fiyatlandirma   # deploy TETIKLEMEZ

# yayina hazir oldugunda
git checkout main
git merge feature/yeni-fiyatlandirma
git push origin main                         # deploy BU push ile baslar

Когда push не появляется

Деплой выглядит магией ровно до того момента, когда он молча ничего не делает, — поэтому диагностируйте в том порядке, в котором работает цепочка.

Начните с конца: сборка вообще стартовала? Если для вашего push сборки нет, сломалось звено подключения — подключены не тот репозиторий или не та ветка, либо интеграция потеряла доступ (отозванная установка, переименованный или перенесённый репозиторий). Если сборка стартовала и упала, лог сборки покажет ровно где; чаще всего причина — шаг в Dockerfile, который локально проходит из-за файла, исключённого вашим `.dockerignore`, либо установка зависимости, которой нужны учётные данные, недоступные сборке. Если сборка прошла успешно, но вы всё ещё видите старую версию, вы почти наверняка смотрите на закешированный ответ, а не на устаревшее приложение — запросите страницу с обходом кеша или проверьте заголовок статуса кеша, прежде чем подозревать деплой.

Один неочевидный случай, который стоит знать: повторный запуск деплоя для commit, который уже упал, сам по себе ничего не исправит. Commit — это входные данные; если вход не изменился, не изменится и результат. Запушьте исправление — пусть даже пустой commit — вместо того чтобы повторять тот же самый.

Проверьте состояние и запустите деплой из терминала

# calisan uygulamanin durumu
cdnctl container apps list --account <uuid>

# son deploy ne yapti
cdnctl container apps logs --account <uuid> --app <app_uuid>

# elle yeniden dagit (ayni commit)
cdnctl container apps deploy --account <uuid> --app <app_uuid>

Что вы получаете, когда это становится скучным

Настоящая выгода деплоя через git — не скорость, а то, что деплой перестаёт быть событием. Когда выпуск — это push, небольшие изменения уходят в продакшен сами по себе, а не копятся в рискованный ежемесячный релиз, — и именно небольшие изменения поддаются отладке, потому что при поломке вы точно знаете, какой commit её вызвал.

Это ещё и превращает откат в обычную операцию, а не в аварию: предыдущий образ никуда не делся, и возврат к нему — такой же деплой, как любой другой. Команды, которые выпускают ежедневно, не смелее тех, кто выпускает раз в месяц; они просто сделали каждый отдельный деплой достаточно маленьким, чтобы он был неинтересным.