Изменения контента не требуют нового релиза: сохраните их в системе администрирования. Новый релиз нужен, когда меняется код приложения.
1. Подготовьте код
Поля, связи, формы и доступ меняйте в Generator UI, затем выполняйте Generate. Свой Go/React-код изменяйте в custom-зонах. Эти способы работы можно сочетать при каждом обновлении.
Generate сохраняет существующие custom-файлы, но при изменении модели вам нужно учитывать новые поля и типы в собственном коде. Сама генерация не обновляет запущенное приложение.
2. Соберите новую версию
Выберите инструкцию своего режима:
| Режим | Где собирать |
|---|---|
| Source | Обновите Git checkout и собирайте прямо на VPS |
| Archive | На рабочем компьютере или в CI; сохраняйте JSON и архив рядом |
| Registry | На рабочем компьютере или в CI; образы публикуются в registry |
| Prod-local | На компьютере с локальным окружением |
Для prod-local:
bash ./deploy/control build --env local --output local-release-02.json
Для серверного окружения (Source — после git pull --ff-only на VPS):
bash ./deploy/control build --env production --output release-02.json
--output — имя нового файла, который создаст build. Не редактируйте JSON релиза и не перезаписывайте им предыдущую сборку. Во время сборки текущее приложение продолжает работать.
Повторный provision не требуется. Если менялись только настройки доставки/backup, используйте reconfigure, а не выпуск нового кода.
При использовании CI этот шаг выполнит build job после push в main.
3. Установите релиз
Для prod-local:
bash ./deploy/control deploy --env local --release local-release-02.json --confirm local
bash ./deploy/control status --env local --json
Для сервера:
bash ./deploy/control deploy --env production --release release-02.json --confirm production
bash ./deploy/control status --env production --json
Source-команды выполняйте на VPS, Archive/Registry — с управляющего компьютера. В CI вместо этих команд запустите задание deploy для нужной сборки.
Во время deploy приложение временно недоступно. Контроллер останавливает запись, создаёт резервную копию текущего успешного релиза, если backup включён, применяет миграции и запускает новый код. При backup.kind: none копия не создаётся. Новый релиз записывается как текущий только после проверки готовности.
После успешного завершения откройте приложение. up для обновления не подходит: он запускает ранее записанный релиз.
Передумали выпускать собранную версию
Если build завершился, но deploy ещё не запускали, сервер не изменился. Просто не выпускайте эту сборку. Abandon для результата build не нужен: операция на сервере ещё не создавалась.
Если обновление прервалось
Не запускайте новый deploy поверх незавершённой операции. Сначала посмотрите status и следуйте восстановлению операций. Это особенно важно при первой установке: таблицы уже могли появиться, хотя успешного релиза ещё нет.
Вернуться к предыдущему коду
Возьмите ID ранее успешного релиза из истории окружения:
bash ./deploy/control rollback --env production --release RECORDED_RELEASE_ID --confirm production
Здесь --release принимает ID, а не путь к JSON. Rollback возвращает код, но не откатывает SQL-миграции и данные. Контроллер проверит совместимость старого кода с миграциями. Для возврата данных нужен restore из резервной копии.
Смену доставки или backup выполняйте через reconfigure, отдельно от выпуска кода.
После успешного выпуска
Backend и frontend заменяются контейнерами нового релиза. PostgreSQL и его постоянные данные сохраняются. Старые образы и архивы автоматически не очищаются. Если диск заполняется, следуйте очистке диска: оставьте текущий и один предыдущий релиз для отката. Это относится и к ops, а не только к backend и admin.