Обновление через GitLab Source CI
Если выбран GitLab + Build on server, обычный выпуск выглядит так:
- Измените модель и custom-код локально. Выполните Save → Generate и примените нужные локальные миграции через
make migrate. - Закоммитьте изменения и влейте их в Release branch, заданную в Deployment → Defaults.
- В pipeline нажмите admingen-deploy. В Source отдельного Build-job нет: build и установка выполняются в этом job на VPS.
- Дождитесь успешной проверки готовности. Предыдущий релиз остаётся записанным для явного отката.
Provision повторять не нужно. Reconfigure требуется только для поддерживаемого изменения настроек окружения, а не для каждого нового коммита. Локальные записи не заменяют данные сервера при Deploy. Первоначальный дамп переносят отдельным действием.
CI собирает точный коммит в отдельной рабочей копии; незакоммиченные серверные правки в него не попадут. Сборки разных проектов одного Unix-пользователя на VPS выполняются по очереди. Пока идёт build, работает старая версия; установка создаёт короткий перерыв. При сбое после начала установки сначала разберите состояние операции.
Подробности: GitLab CI. Ниже — ручные команды и другие режимы.
Изменения контента не требуют нового релиза: сохраните их в системе администрирования. Новый релиз нужен, когда меняется код приложения.
В командах ниже ENV_NAME — переменная оболочки с именем профиля из Deployment environments, а не именем проекта и не preset. В начале каждого блока замените значение production, local или dev своим именем, например ENV_NAME=test. Команды используют "$ENV_NAME", поэтому --env и подтверждение получают одно и то же значение. При переходе на другую машину или в новый терминал задайте переменную снова.
1. Подготовьте код
Поля, связи, формы и доступ меняйте в Generator UI, затем выполняйте Generate. Свой Go/React-код изменяйте в custom-зонах. Эти способы работы можно сочетать при каждом обновлении.
Generate сохраняет существующие custom-файлы, но при изменении модели вам нужно учитывать новые поля и типы в собственном коде. Сама генерация не обновляет запущенное приложение.
2. Соберите новую версию
Выберите инструкцию своего режима:
| Режим | Где собирать |
|---|---|
| Source | Обновите Git checkout и собирайте прямо на VPS |
| Archive | На рабочем компьютере или в CI; сохраняйте JSON и архив рядом |
| Registry | На рабочем компьютере или в CI; образы публикуются в registry |
| Prod-local | На компьютере с локальным окружением |
Для prod-local:
ENV_NAME=local # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control build --env "$ENV_NAME" --output local-release-02.json
Для серверного окружения (Source — после git pull --ff-only на VPS):
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control build --env "$ENV_NAME" --output release-02.json
--output — имя нового файла, который создаст build. Не редактируйте JSON релиза и не перезаписывайте им предыдущую сборку. Во время сборки текущее приложение продолжает работать.
Повторный provision не требуется. Если менялись только настройки доставки/backup, используйте reconfigure, а не выпуск нового кода.
В Archive/Registry CI создаёт кандидат в Build, а в Source — внутри Deploy на VPS. Релизная ветка задаётся настройкой Release branch.
3. Установите релиз
Для prod-local:
ENV_NAME=local # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control deploy --env "$ENV_NAME" --release local-release-02.json --confirm "$ENV_NAME"
bash ./deploy/control status --env "$ENV_NAME" --json
Для сервера:
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control deploy --env "$ENV_NAME" --release release-02.json --confirm "$ENV_NAME"
bash ./deploy/control status --env "$ENV_NAME" --json
Source-команды выполняйте на VPS, Archive/Registry — с управляющего компьютера. В CI вместо этих команд запустите задание deploy для нужной сборки.
Во время deploy приложение временно недоступно. Контроллер останавливает запись, создаёт резервную копию текущего успешного релиза, если backup включён, применяет миграции и запускает новый код. При backup.kind: none копия не создаётся. Новый релиз записывается как текущий только после проверки готовности.
После успешного завершения откройте приложение. up для обновления не подходит: он запускает ранее записанный релиз.
Передумали выпускать собранную версию
Если build завершился, но deploy ещё не запускали, сервер не изменился. Просто не выпускайте эту сборку. Abandon для результата build не нужен: операция на сервере ещё не создавалась.
Если обновление прервалось
Не запускайте новый deploy поверх незавершённой операции. Сначала посмотрите status и следуйте восстановлению операций. Это особенно важно при первой установке: таблицы уже могли появиться, хотя успешного релиза ещё нет.
Вернуться к предыдущему коду
Возьмите ID ранее успешного релиза из истории окружения:
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control rollback --env "$ENV_NAME" --release RECORDED_RELEASE_ID --confirm "$ENV_NAME"
Здесь --release принимает ID, а не путь к JSON. Rollback возвращает код, но не откатывает SQL-миграции и данные. Контроллер проверит совместимость старого кода с миграциями. Для возврата данных нужен restore из резервной копии.
Смену доставки или backup выполняйте через reconfigure, отдельно от выпуска кода.
После успешного выпуска
Backend и frontend заменяются контейнерами нового релиза. PostgreSQL и его постоянные данные сохраняются. Старые образы и архивы автоматически не очищаются. Если диск заполняется, следуйте очистке диска: оставьте текущий и один предыдущий релиз для отката. Это относится и к ops, а не только к backend и admin.