CI/CD

Все репозитории экосистемы используют GitHub Actions. Эта страница описывает общие шаблоны и соглашения.

Основные принципы

1. Проверяем на PR, разворачиваем на main. PR запускает сборку и тесты и ничего не деплоит. Деплой стартует только после слияния в main.
2. Собираем только изменившееся. С помощью paths-filter определяется, что изменилось, и пересобираются только эти сервисы.
3. Никаких одновременных деплоев. Группа concurrency ставит production- деплои в очередь, так что параллельно они не идут.
4. Секреты только в GitHub Secrets. В файле workflow они не пишутся никогда.

Типичная структура workflow

name: deploy

on:
  push:
    branches: [main]
    paths:
      - 'backend/**'
      - 'frontend/**'
      - '.github/workflows/deploy.yml'
  workflow_dispatch:          # возможность ручного запуска

concurrency:
  group: deploy-production
  cancel-in-progress: false   # деплой не прерываем на середине

cancel-in-progress: false — это важно

Прерванный на середине деплой может оставить незавершённое состояние: новый контейнер не поднялся, старый уже погашен. Деплою нужно дать дойти до конца, а следующий поставить в очередь.

Стадия проверок (PR)

Проверка	Что делает
Сборка	Компилируется ли код
Модульные тесты	Бизнес-логика
Интеграционные тесты	testcontainers — настоящие PostgreSQL/Redis
Lint	Стиль кода
Строгая сборка документации	Выявляет битые ссылки и отсутствующие файлы

Строгая проверка документации

MkDocs собирается в режиме --strict. В этом режиме предупреждения становятся ошибками:

• битые внутренние ссылки,
• файлы, указанные в nav, но отсутствующие,
• файлы, которые есть, но не включены в nav.

Так поломка документации не доходит до production.

Стадия деплоя

Выполняется подключением к хосту по SSH. Необходимые секреты (общая нотация):

Секрет	Значение
DEPLOY_HOST	Адрес сервера
DEPLOY_USER	Пользователь SSH
DEPLOY_SSH_KEY	Приватный ключ
DEPLOY_PORT	Порт SSH (необязательно, по умолчанию 22)
DEPLOY_PATH	Путь на хосте

SSH-ключ, а не пароль

Для деплоя используется SSH-ключ, а не пароль. Ключ легко отозвать, он реже случайно попадает в логи, и его можно ротировать, не раздавая заново множеству людей.

Частичная сборка

В монорепозитории одно изменение не должно требовать сборки всех сервисов:

- uses: dorny/paths-filter@v3
  id: filter
  with:
    filters: |
      backend: 'backend/**'
      frontend: 'frontend/**'
      edge: 'nginx/**'

Далее пересобираются только изменившиеся сервисы. Если изменился edge (nginx), полной пересборки нет — только синхронизация конфига + nginx -t + reload.

Деплой конфигурации edge

conf.d у edge nginx управляется через git. Порядок деплоя:

1. Синхронизировать репозиторий на хосте: git fetch && git reset --hard,
2. docker exec <nginx> nginx -t — проверить конфигурацию,
3. При успехе — nginx -s reload.

nginx -t пропускать нельзя

Reload с неверным конфигом приведёт к тому, что nginx не поднимется, — и в этот момент упадут все домены. nginx -t должен выполняться до reload, и при ошибке деплой обязан остановиться.

Self-hosted runner

Для сборок под iOS и Windows (подписание кода, нотаризация, упаковка MSIX) используются self-hosted раннеры macOS / Windows. Им нужны специфические инструменты платформы и сертификаты, поэтому на облачных раннерах они не работают.

Версионирование и откат

• У образов есть теги. Переменной <SVC>_IMAGE_TAG на хосте можно закрепить конкретную версию.
• Для статических сайтов заново распаковывается архив предыдущей сборки.

CI/CD этого репозитория

У репозитория docs-gerege-mn два workflow:

Workflow	Когда	Что делает
ci.yml	PR + push в main	Сборка MkDocs --strict; оставляет артефакт
deploy.yml	Push в main + вручную	Сборка → копирование → обновление контейнера → установка edge vhost → проверка живого сайта

Подробности — на странице Платформа этой документации.