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

Эта инструкция использует окружение production и ветку main. Сервер и профиль окружения подготовьте по общей инструкции CI/CD.

1. Создайте CI-файлы

В Deployment включите Docker и Production deployment. Выберите CI provider — GitLab. В Deployment environments создайте профиль production, заполните серверы и домены, выберите доставку Archive или Registry. Сохраните настройки, выполните Generate и добавьте сгенерированный профиль и custom-файл без секретов в Git.

В проекте появятся .gitlab-ci.yml, .gitlab/admingen.yml и deploy/custom/gitlab.yml. Первые два файла обновляет генератор, свои задания добавляйте в deploy/custom/gitlab.yml.

Создайте GitLab-репозиторий, загрузите проект и защитите ветку main.

2. Подготовьте runner

Нужен GitLab Runner с Docker executor и Docker-in-Docker. Шаблон использует docker:29.3.1-cli и docker:29.3.1-dind с TLS.

В настройках runner разрешите privileged mode для DinD, общий каталог сертификатов /certs/client и общий /builds между job и DinD. Runner должен принимать задания проекта, включая задания защищённой ветки; шаблон не назначает им tags. В GitLab проверьте доступность runner в Settings → CI/CD → Runners.

3. Добавьте настройки сборки

По умолчанию pipeline использует профиль production из Git. Для другого имени задайте переменную ADMINGEN_ENVIRONMENT со scope *. Сгенерированный и custom-файл этого профиля должны быть закоммичены.

Если вам нужен полный конфиг вне Git, создайте ADMINGEN_BUILD_ENVIRONMENT_JSON типа File со scope * и ADMINGEN_ENVIRONMENT_JSON типа File со scope нужного окружения. Вставьте полное содержимое собственного ручного JSON. Эти переменные полностью перекрывают UI/custom; для обычного профиля не создавайте их.

Остальные переменные добавляются в Settings → CI/CD → Variables.

Если доставка Registry, добавьте защищённые переменные типа Variable со scope *:

Для registry этого GitLab можно использовать автоматически предоставляемые CI_REGISTRY_USER и CI_REGISTRY_PASSWORD: шаблон подставит их, если registry-хост совпадает с CI_REGISTRY и своя пара не задана. Для другого registry задайте обе переменные. При Archive они не нужны.

4. Добавьте настройки выпуска

Создайте environment production и ограничьте круг пользователей, которым разрешён выпуск. При необходимости настройте доступные для вашего проекта approvals.

Добавьте защищённые переменные типа File, теперь со scope production:

Используйте ключ и known_hosts, подготовленные для ручного управления сервером. Сохраните переводы строк. Пароли PostgreSQL и ключи подписи приложения в эти переменные не добавляются.

Для Registry при необходимости задайте ADMINGEN_REGISTRY_USER и ADMINGEN_REGISTRY_PASSWORD типа Variable со scope production. Это доступ runner к образам для выпуска; используйте токен чтения. Встроенные GitLab credentials подходят только для совпадающего registry-хоста. Сервер использует свой постоянный токен, настроенный при provisioning.

Конфигурации build и deploy должны описывать одно окружение и одинаковую доставку. Archive не требует registry-переменных ни для сборки, ни для выпуска. Для токенов включите masking, если формат значения его поддерживает.

5. Соберите и выпустите приложение

1. Отправьте код в main.
2. Откройте Build → Pipelines и pipeline этого push.
3. Дождитесь успешного задания admingen-build.
4. Для первой установки скачайте артефакты и выполните provision по инструкции Archive или Registry. Повторно собирать скачанный релиз не нужно.
5. В том же pipeline вручную запустите admingen-deploy. Пройдите approval, если он настроен.
6. Дождитесь успешного завершения и откройте приложение.

При Registry build публикует образы и сохраняет release.json. При Archive сохраняет также *.images.tar. Артефакты доступны 90 дней. Deploy получает готовую сборку из того же pipeline и проверяет её commit; повторной сборки при выпуске нет.

6. Добавьте обслуживание по расписанию

Создайте environment production-maintenance, разрешите работу из main и добавьте те же File variables из шага 4 с этим scope. Для Registry добавьте и credentials чтения, если они нужны. Ручное подтверждение каждого запуска здесь не требуется.

Задания обслуживания используют профиль production: отдельное CI environment ограничивает доступ, но не создаёт вторую БД или второй сервер.

Создайте pipeline schedule для main, задайте время и переменные:

ADMINGEN_ENVIRONMENT=production
ADMINGEN_OPERATION=maintenance

Maintenance создаёт резервную копию, затем обслуживает сертификаты. При backup.kind: none копия пропускается. Для отдельного расписания можно выбрать ADMINGEN_OPERATION=backup или certificates; явный backup при None завершится ошибкой.

Расписание в GitLab создаётся вручную. Push выполняет build, schedule — обслуживание; автоматического выпуска нового кода по расписанию нет.

Если задание не запускается