GitLab CI/CD: настройка и выпуск

GitLab может собирать приложение на VPS или на runner. Выберите способ в Deployment → Defaults: от него зависит состав pipeline. Исходный код, локальная БД и серверная БД обновляются отдельно.

1. Настройте генератор

Выберите CI provider: GitLab, задайте Release branch и оставьте Automatic deploy выключенным для первого выпуска. По умолчанию релизная ветка — main; если используете production, укажите это имя и защитите эту ветку в GitLab.

В Deployment → Environments нажмите + Create, создайте профиль, например production, и заполните его. Имя профиля выбирает ADMINGEN_ENVIRONMENT в CI; по умолчанию используется production. Оно не обязано совпадать с именем Git-ветки.

После Save → Generate закоммитьте .gitlab-ci.yml, .gitlab/admingen.yml, модель, generated-профиль и его custom-файл. Своим заданиям выделен deploy/custom/gitlab.yml.

2. Выберите, где собирать

Source: подготовить сервер

В Defaults выберите Build on server и заполните Source repository on server, например /home/deploy/projects/PROJECT_NAME. Это Git checkout, а не Runtime directory. В профиле выберите Single server, Source и Backend SSH target, например deploy@YOUR_SERVER_HOST.

На VPS нужны Docker/Compose, Git, Bash, jq и flock. Создайте runtime root с владельцем deployment-пользователем, клонируйте туда, где указано Source repository, именно этот GitLab-проект. Origin должен указывать на его GitLab URL без встроенного пароля. Серверу нужен собственный read-only Deploy key для чтения репозитория. Один раз выполните git fetch origin под тем же Unix-пользователем и настройте доступ.

Ключ для чтения GitLab на VPS и ключ, которым CI входит на VPS, выполняют разные задачи. Добавление одного не настраивает второй автоматически.

Archive и Registry: подготовить runner

Для этих двух режимов нужен Docker executor с privileged Docker-in-Docker, TLS, общим /certs/client и checkout под /builds, доступным job и DinD. Source использует лёгкий SSH job и DinD не требует. Registry может быть GitLab, GHCR, Docker Hub или собственный сервис.

3. Добавьте CI-переменные

В настройках GitLab CI/CD задайте защищённые File-переменные:

Для обычного профиля больше не нужен полный JSON в переменных: CI читает generated-профиль и custom overlay из коммита. ADMINGEN_ENVIRONMENT_JSON — необязательный полный File-override; он имеет приоритет над Git. Удалите старый Archive override при переходе на Source. Source не использует ADMINGEN_BUILD_ENVIRONMENT_JSON.

Для Registry доступны ADMINGEN_BUILD_REGISTRY_USER/PASSWORD для публикации и ADMINGEN_REGISTRY_USER/PASSWORD для выпуска. Archive и Source не требуют registry credentials. Не вставляйте секреты в модель, JSON-профиль, скриншоты или Git.

Переменные ADMINGEN_RELEASE_BRANCH, ADMINGEN_AUTO_DEPLOY, ADMINGEN_ENVIRONMENT и ADMINGEN_SOURCE_DIRECTORY при необходимости явно переопределяют настройки/выбор CI. Оставьте их незаданными, если хотите пользоваться значениями из UI. Scope должен разрешать доступ выбранному CI environment; расписания maintenance могут использовать отдельный environment.

4. Первый запуск

Подготовьте VPS и домены. Для external ingress внешний Nginx и HTTPS должны быть настроены заранее; сгенерированный frontend слушает выделенный loopback-порт.

Для Source в pipeline защищённой релизной ветки нажмите admingen-provision, дождитесь успеха, затем admingen-deploy. Каждый job собирает свой кандидат на VPS. Аккаунт первого администратора и первоначальные данные создаются отдельными действиями. Для уже работающего приложения используйте только Deploy.

В Archive/Registry дождитесь admingen-build. Первоначальный provision и deploy используют его артефакт. При последующих обновлениях provision не повторяют.

5. Обычное обновление

Измените модель и custom-код локально, выполните Save → Generate, примените локальные миграции и закоммитьте изменения. Влейте их в выбранную релизную ветку и нажмите admingen-deploy.

В Source CI получает точный SHA pipeline в отдельную рабочую копию под RUNTIME_ROOT/ci-source/worktrees/; основной серверный checkout не сбрасывается. Он проверяет актуальность релизной ветки, собирает образы, запускает обычный controller и проверяет готовность. Все Source CI проекты одного Unix-пользователя на VPS ждут общий host lock. Это очередь сборок, а не общая БД проектов.

Пока идёт build, работает прежний релиз. Во время установки есть короткий перерыв: controller останавливает запись, выполняет разрешённые операции backup/миграций и запускает новую версию. Серверные записи, аккаунты и файлы сохраняются. Локальный дамп повторно не загружается. При ошибке build текущая версия остаётся работать; при ошибке уже начавшегося deploy посмотрите состояние операции, прежде чем повторять запуск.

Automatic deploy можно включить в UI после проверки первого релиза. Сохраните, сгенерируйте и опубликуйте изменение. Approvals GitLab, если они настроены, сохраняют своё действие.

6. Обслуживание и ошибки

Ручной admingen-stop останавливает весь стек, включая PostgreSQL. Это отдельное действие, а не шаг каждого обновления.

Для schedule выберите защищённую релизную ветку и ADMINGEN_OPERATION=maintenance, backup или certificates. При backup None общий maintenance пропускает копирование; отдельный backup завершится ошибкой. Для external ingress сертификаты внешнего Nginx обслуживает его оператор.

Архивы Source остаются на самом VPS для работы controller; Archive/Registry CI сохраняет артефакты на 90 дней. Периодически проверяйте расход диска.