Итоги и практика

Ключевые выводы

• Выпуск — это рабочий процесс, а не момент: разверни, наблюдай, чини, повторяй — и сделай откат тем, что ты уже однажды протестировал.
• Прогони чек-лист перед запуском, прежде чем что-либо анонсировать, и поручи AI проверить каждый пункт вместо опоры на память.
• Пусть измерения управляют оптимизацией — отчёт Lighthouse всегда лучше догадки о том, что «кажется медленным».
• Секреты живут в продакшен-конфигурации, никогда в репозитории; .env в gitignore, а .env.example остаётся актуальным.
• Первая версия — это гипотеза, а реальные пользователи — эксперимент, поэтому итерируй маленькими быстрыми правками.

Попробуй сам

Возьми развёрнутое приложение (или разверни сейчас крошечное) и пройди по нему полный чек-лист перед запуском строчка за строчкой. Для каждого пункта, который ты не можешь честно отметить, вставь проваленный пункт в AI и попроси наименьшее изменение, закрывающее пробел. Заверши, кликнув глубокую ссылку на живом сайте — а не только домашнюю страницу — чтобы убедиться, что продакшен ведёт себя как дев.

Промпт главы

Here is my deployed app and its stack: [describe app + hosting + services].
Act as my launch reviewer. Walk this pre-launch checklist item by item
and, for each, tell me how to verify it on the LIVE site (not in dev):
- production URL loads over valid HTTPS on the custom domain
- all secrets set in production; none committed to the repo
- core happy path (sign-up, login, main action) works in production
- payments tested end-to-end including the webhook (if any)
- error tracking and uptime monitoring are live
- I can roll back, and have tested it once
- mobile layout works on a real phone
- database backups are enabled
For every item that fails, give me the SMALLEST change that fixes it.
Do not assume anything passes — make me prove each one.