Проблема SFTP и ручных деплоев
Деплой перетаскиванием файлов по SFTP — способ, которым сайты оказываются наполовину сломанными: файл пропущен, composer не запущен, миграция забыта, а кэш всё ещё отдаёт старый бандл. Нет записи о том, что было выпущено, и нет чистого способа это воспроизвести. GitHub Deploy заменяет это определённым пайплайном, привязанным к вашему репозиторию, так что релиз — детерминированный результат коммита плюс фиксированный набор шагов — один и тот же каждый раз, кем бы из команды он ни выполнялся.
Ваши шаги сборки, выполняемые стабильно
Настоящий деплой — больше, чем копирование файлов: зависимости должны быть установлены, ресурсы скомпилированы, а миграции базы данных применены в правильном порядке. Вы определяете эти шаги один раз — например composer install, сборку npm или ресурсов и команду миграции — и они выполняются при каждом деплое ровно на том коммите, который выкатывается. Это убивает целый класс багов, когда продакшн ведёт себя иначе, потому что кто-то выполнил шаги в другом порядке или пропустил один под давлением.
Ручные деплои и авто-деплой по webhook
Разным командам нужны разные триггеры. Осторожная команда держит деплои ручными, нажимая деплой в панели после ревью, так что релиз — осознанное действие. Быстро движущаяся команда включает webhook, чтобы каждый push в продакшн-ветку выкатывался автоматически, превращая git push в деплой. Оба варианта выполняют один и тот же пайплайн; разница только в том, что нажимает на спусковой крючок, и вы можете начать с ручного режима и включить webhook, когда доверитесь процессу.
Приватные репозитории и безопасные токены
Большая часть реального кода находится в приватных репозиториях, поэтому платформа аутентифицируется с помощью предоставленного вами токена, а не требует публичности кода. Токен хранится как секрет и используется только для клонирования в момент деплоя; после сохранения он не отображается в логах или интерфейсе, а поскольку он отделён от вашего кода, вы можете ротировать или отозвать его независимо. Доставки webhook проверяются подписанным секретом, так что случайный POST не может запустить релиз.
Auto-purge закрывает последний разрыв
Самый частый баг после деплоя — свежий релиз, скрытый за устаревшим edge-кэшем: новые CSS или JS выкачены, но посетители всё ещё загружают старый, кэшированный бандл. GitHub Deploy очищает edge-кэш как часть релиза, так что деплой не считается завершённым, пока кэш не отражает новые файлы. Это устраняет ручной шаг сброса, о котором люди забывают, и означает, что то, что вы выкатили, — это именно то, что реально получают посетители.
Повторяемая доставка для команд и агентств
Когда каждый проект деплоится одинаково, онбординг и передача перестают быть племенным знанием. Статус деплоя, время последнего деплоя и настроенные шаги видны в панели, так что любой может увидеть, дошёл ли последний push до продакшна и что при этом выполнялось. Для агентств это означает стандартную модель доставки во всех клиентских проектах, где передача сайта другому разработчику не требует реверс-инжиниринга особого, недокументированного ритуала деплоя.
Как развернуть, шаг за шагом
Подключите репозиторий и ветку
В панели откройте своё приложение, перейдите в GitHub Deploy и введите URL репозитория и ветку, из которой вы деплоите — обычно main или production. Выбранная ветка становится активной, так что feature-ветки никогда не выкатываются случайно.
Авторизуйте приватный репозиторий
Если репозиторий приватный, добавьте personal access token или deploy-токен, чтобы платформа могла его клонировать. Токен хранится как секрет, используется только для получения кода в момент деплоя и может быть отозван или ротирован без изменений в вашем приложении.
Определите шаги сборки и миграций
Задайте команды, превращающие checkout в работающий релиз — для PHP-приложения это обычно composer install --no-dev, сборка фронтенд-ресурсов и миграция базы данных. Эти шаги сохраняются вместе с приложением, так что каждый деплой выполняет идентичный пайплайн, а не то, что кто-то вспомнит напечатать.
Выберите ручной или авто-деплой по webhook
Деплойте по требованию кнопкой в панели или включите webhook, чтобы push в подключённую ветку автоматически запускал деплой. Webhook использует подписанный секрет, так что запустить релиз могут только настоящие push из вашего репозитория.
Выпустите, очистите кэш и подтвердите
При деплое платформа забирает ветку, выполняет ваши шаги и активирует новый релиз; edge-кэш для изменённых ресурсов очищается автоматически, так что посетители не получают устаревшие файлы. Панель показывает статус деплоя и время последнего деплоя, чтобы вы могли подтвердить, что релиз активен.
Примеры сценариев
Push в main запускает composer install, сборку ресурсов и миграции, затем релиз выкатывается, а edge-кэш очищается автоматически.
Агентство подключает приватный репозиторий GitHub с ограниченным по правам deploy-токеном, оставляя код закрытым, пока платформа всё равно забирает и деплоит его.
Команда держит авто-деплой выключенным и нажимает деплой в панели после ревью кода, так что каждый продакшн-релиз — осознанное, зафиксированное действие.
Часто задаваемые вопросы
GitHub Deploy собирает образ Docker или деплоит исходный код?
Он деплоит исходный код приложения в runtime платформы — забирает вашу ветку и выполняет шаги сборки и миграций прямо на коде. Это естественный вариант для PHP и фреймворковых приложений. Если вам конкретно нужен собранный и запущенный образ контейнера, используйте вместо этого Container Apps с готовым образом или Docker Compose Instant Deploy.
Что именно происходит при push через webhook?
Push в подключённую ветку отправляет подписанный webhook платформе, которая проверяет подпись, клонирует или получает этот коммит, выполняет ваши определённые шаги сборки и миграций, активирует новый релиз и очищает edge-кэш. Затем панель обновляет статус деплоя и время последнего деплоя, чтобы вы могли подтвердить, что он применился.
Как защищён мой access-токен?
Токен хранится как секрет и используется только для клонирования репозитория в момент деплоя. Он не отображается после сохранения и не появляется в логах сборки, а поскольку он живёт отдельно от вашего кода, вы можете ротировать или отозвать его в GitHub, ничего не меняя в приложении.
Могу ли я откатиться, если деплой прошёл неудачно?
Поскольку деплои привязаны к коммитам и определённым шагам, восстановление сводится к деплою заведомо рабочего коммита — вы направляете деплой на предыдущий рабочий коммит или откатываете ветку и даёте пайплайну его выкатить. Именно воспроизводимость деплоев делает откат надёжным, а не авралом.
Какая ветка становится активной и могу ли я деплоить из нескольких?
Вы выбираете ветку для деплоя, обычно main или выделенную продакшн-ветку, и выкатывается только она — push в feature-ветки не деплоятся. Это держит незавершённую работу вне продакшна, при этом позволяя деплоить сразу после merge в релизную ветку.
Работает ли это с GitLab или другими Git-хостингами, или только с GitHub?
Рабочий процесс построен вокруг URL Git-репозитория, ветки и токена, так что он не ограничен конкретно GitHub — любой репозиторий, доступный по URL и access-токену, вписывается в ту же модель. GitHub — распространённый случай, отсюда и название, но механика — стандартный Git.