что проверить перед первым деплоем

проверяй сборку, которую отправляешь

сервер разработки многое прощает. перед публикацией собери production-версию и открой именно её. убедись, что стили, шрифты, изображения и переходы работают после прямого открытия вложенной страницы, а не только после клика с главной. команды в примере подходят проектам с соответствующими npm-скриптами; в своём репозитории проверь package.json.

npm run lint
npx tsc --noEmit
npm run build
# Затем проверь собранную версию

домен — тоже часть приложения

проверь https, основной адрес, редиректы с www, canonical и страницу 404. если несколько сайтов работают на одном worker, запрос /api на публичном блоге не должен случайно попадать в api личного кабинета. маршрутизация по хосту должна быть явной.

не забудь узкий экран

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

секреты и наблюдаемость

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

оставь путь назад

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