Развёртывание

Перед первым деплоем

Подготовьте PostgreSQL database и отдельную schema, DNS-имя с HTTPS, SMTP с подтверждённым sender и длинные случайные secrets. Runtime user должен иметь DML-доступ; для DDL можно задать отдельный MIGRATION_DATABASE_URL.

Обязательные production-переменные:

DATABASE_URL="postgresql://app:secret@db:5432/database?schema=itam"
DATABASE_SCHEMA="itam"
MIGRATION_DATABASE_URL="postgresql://migration:secret@db:5432/database?schema=itam"
BETTER_AUTH_SECRET="at-least-32-random-characters"
BETTER_AUTH_URL="https://itam.example.com"
AUTH_ADMIN_NAME="Initial Owner"
AUTH_ADMIN_EMAIL="owner@example.com"
AUTH_ADMIN_PASSWORD="one-time-strong-password"
SMTP_HOST="smtp.example.com"
SMTP_PORT="587"
SMTP_SECURE="false"
SMTP_USER="smtp-user"
SMTP_PASSWORD="smtp-password"
SMTP_FROM="ITAM <no-reply@example.com>"
CRON_SECRET="independent-long-random-secret"

AUTH_ADMIN_* нужны для bootstrap Owner. Не храните значения в Git и смените пароль сразу после первого входа. NEXT_PUBLIC_* попадают в browser bundle и не должны содержать secrets.

Startup sequence

При старте production-контейнер:

Ошибка любого startup-шага должна остановить новую версию. При стратегии start-first старый healthy container может продолжать обслуживать домен, даже если новый image успешно собрался, но не прошёл migration или seed.

Проверка после деплоя

curl --fail https://itam.example.com/health

Ожидаемый ответ:

{"status":"ok"}

Дополнительно проверьте login, открытие registry и asset detail, запись в Audit Log, отправку тестового письма и ручной запуск обоих cron endpoint.

Rollback

1. Зафиксируйте failing commit, startup log и migration name.
2. Если схема совместима, верните предыдущий image и дождитесь healthy status.
3. Если migration необратимо изменила данные, остановите запись и восстановите проверенный backup в согласованную точку.
4. Повторите smoke test и зафиксируйте incident.