В июне наши сгенерированные приложения работали в средах предпросмотра. Я мог разглядывать экран, пока конвейер его менял. В разработке это было полезно. Но пускать клиентов в ту же среду я бы не стал.
Мы решили отделить продакшен от этого цикла правок и наладить передачу проектов через GitHub.
В исходной заметке о релизе я описал часть этого слишком уверенно; эта редакция отделяет задуманное от того, что мы можем проверить на 15 октября 2026 года. В реализации и документации есть пути для деплоя и для GitHub. Одного этого мало, чтобы считать проверенными все реальные выкаты, смены домена и откаты.
Граница продакшена
Предпросмотр пересобирается, пока ты работаешь. По замыслу между этой меняющейся средой и приложением, которым пользуются люди, стоит осознанный релиз. Деплой в продакшен должен отдавать ту версию, которую ты выбрал.
Хост продакшена задуман так, чтобы работать с заранее собранными артефактами, без инструментов редактирования из предпросмотра. У конфигурации и учётных данных продакшена своя область действия. Конечным пользователям приложения тоже нужна своя настройка идентификации, отдельная от аккаунтов, которыми пользовались при разработке.
То, что настройка хранится отдельно, ещё не доказывает, что каждая ветка кода обрабатывает её правильно. Прежде чем отправить клиенту ссылку, проверь значения для продакшена, разрешённые перенаправления и правила доступа.
Пройдись по приложению в предпросмотре, не забыв про права доступа и экраны без данных. Потом настрой среду продакшена, опубликуй, дождись готовности и прогони важные сценарии на развёрнутом приложении.
Актуальное руководство по публикации описывает эти шаги и то, как свериться с лимитами твоего плана. Успешную операцию в интерфейсе считай одним из шагов релиза, а потом проверь сервис, который получился.
Домен
Процесс подключения домена связывает имя хоста приложения с доменом, который ты контролируешь: понадобятся соответствующие записи DNS, а подключение придётся подтвердить.
Исходная статья сводила это к тому, что достаточно добавить CNAME — и всё заработает, а ожидание и проверки, которых требует смена домена, оставались за кадром.
Используй значения, показанные для деплоя. Когда DNS начнёт разрешаться, проверь имя хоста, сертификат и само приложение. На публичном адресе перепроверь перенаправления при входе. Работающий адрес предпросмотра об этом последнем пункте почти ничего не скажет.
В реализации есть пути для настройки домена. Но эта редакция — не отчёт о свежей проверке DNS или TLS вживую.
Передача через GitHub
Я хочу, чтобы проект оставался полезным и за пределами сессии, в которой он появился. Репозиторий даёт изменениям кода место, где их проверяют и поддерживают.
В интеграции с GitHub есть пути, чтобы подключить аккаунт, опубликовать код и обмениваться изменениями с подключённым репозиторием. После этого код проекта и сопроводительные документы можно изучать в привычных инструментах.
Публикация кода на GitHub и публикация работающего приложения — разные операции. Репозиторий не обслуживает базу данных, не настраивает твои секреты и не реагирует на инциденты в продакшене.
Схема работы с историей такая: одна основная ветка, обычный push, а изменения отменяются новыми revert-коммитами поверх уже сделанных. Force-push как обычное действие платформы мы стараемся не предлагать.
Так у нашего собственного процесса меньше способов переписать историю, но обещать на этом основании, что пользователь никогда не потеряет код, нельзя. Права доступа к репозиторию, правки извне и процедуры восстановления по-прежнему важны.
На октябрь часть сценариев с просмотром истории и откатом ещё не прошла свежих эксплуатационных проверок. Держи собственный план восстановления. Кнопка или путь в реализации — ещё не повод считать, что восстановление проверено.
Учётные данные и конфигурация
По замыслу интеграция хранит зашифрованные учётные данные GitHub отдельно для каждого проекта, вне проектного диска приложения. Чтобы подключение работало, приложению не должен понадобиться персональный токен доступа в дереве исходников.
Такой способ хранения ещё не значит, что весь деплой прошёл аудит безопасности.
Чтобы перенести проект в другое место, мало скачать исходники: придётся дать ему конфигурацию среды выполнения, сервисы данных и настройки идентификации, которых ждёт его код. Изучи эти зависимости, прежде чем решать, где и как размещать проект.
Документация по Git и GitHub объясняет работу с исходным кодом. А почему вход — это лишь часть границы доступа в приложении, рассказывает статья об идентификации.
Работа над релизом
Для эксплуатационных обещаний мне всё ещё нужны доказательства: завершённый выкат, работающий домен, восстановление, отработанное на реальном сервисе. Код-ревью таких доказательств не даст.
Июньская работа дала нам пути для этих задач. Записывать проверки, которых им ещё не хватает, не так приятно, как объявить проблему решённой. Зато это полезнее, пока на эти пути не положился первый клиент.
Впервые опубликовано 16 июня 2026 года. Отредактировано 15 октября 2026 года: исправлены безоговорочные утверждения о деплое и восстановлении, а реализованные пути отделены от проверки вживую.