GitHub Actions: автоматизация релизов

(Раздел: Технологии и Инфраструктура)

Краткое резюме

GitHub Actions — нативный «конвейер как код» в репозитории. Для iGaming это быстрые и безопасные релизы бэкендов, фронтендов, ETL/DBT и ML/LLM-сервисов: матрицы тестов, кэш зависимостей, изолированные runner-пулы, Reusable Workflows для единых стандартов, OIDC вместо долгоживущих секретов, подпись и SBOM, релизы по тэгам и GitOps-бампы манифестов. Ключ — шаблоны и гейты качества/безопасности, чтобы держать p99 и стоимость под контролем.

1) Архитектурные принципы

Пайплайны как код (`.github/workflows/.yml`), DRY через Reusable/Composite Actions.
Runner-пулы: хостed (ubuntu-latest) + self-hosted (K8s/VM, GPU для ML).
Среды (Environments): `dev/stage/prod` с required reviewers, таймаутами и секретами по окружениям.
Политики: protected branches/tags, CODEOWNERS, обязательные проверки.
Наблюдаемость: job summaries, артефакты, логирование, метрики длительности.

2) Базовый шаблон CI → CD (backend)

yaml name: ci-cd-backend on:
pull_request:
branches: [ main ]
push:
tags: [ "v" ]
permissions:
contents: read id-token: write    # для OIDC packages: write

env:
IMAGE: ghcr. io/${{ github. repository }}/api:${{ github. sha }}

jobs:
lint_test:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5 with: { python-version: '3. 12' }
- name: Cache pip uses: actions/cache@v4 with:
path: ~/.cache/pip key: pip-${{ runner. os }}-${{ hashFiles('requirements. txt') }}
- run: pip install -r requirements. txt
- run: make lint && make test
- name: Build & push image (BuildKit)
uses: docker/build-push-action@v6 with:
push: ${{ github. event_name == 'push' }}
tags: ${{ env. IMAGE }}
cache-from: type=gha cache-to: type=gha,mode=max

security:
needs: [ lint_test ]
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- name: SCA/SAST/Secrets uses: your-org/security-composite@v3  # Composite Action вашей орг.

release_prod:
if: startsWith(github. ref, 'refs/tags/v')
needs: [ security ]
runs-on: ubuntu-latest environment: production steps:
- uses: actions/checkout@v4
- name: SBOM & Sign uses: your-org/sbom-sign-action@v2 with:
image: ${{ env. IMAGE }}
- name: GitOps bump manifests uses: your-org/gitops-bump@v2 with:
image: ${{ env. IMAGE }}
path: apps/api/values. yaml

Идея: PR → линт/юниты → безопасность → по тэгу `v` — SBOM/подпись и GitOps-бамп манифестов для деплоя.

3) Повторное использование: Reusable/Composite

Reusable Workflows: единые pipeline-шаблоны для всех сервисов (в отдельном репо `.github`).
Composite Actions: склейка повторяющихся шагов (линт/юниты/сканы).

yaml jobs:
ci_template:
uses: your-org/ci-templates/.github/workflows/python. yml@v3 with:
python: '3. 12'
run-tests: true

4) Матрицы, кэш и производительность

`strategy.matrix` для параллельных тестов (языки/БД/ОС).
Кэш: `actions/cache` для зависимостей; BuildKit с `cache-to: gha`; dependency proxies.
Конкурентность: `concurrency: group: api-${{ github.ref }}, cancel-in-progress: true` — экономит минуты.
Артефакты: хранить отчеты/покрытие/профили с `retention-days`.

yaml strategy:
matrix:
py: [ '3. 10', '3. 12' ]
db: [ 'mysql', 'postgres' ]

5) Environments и approvals

Настройте required reviewers для `production` (ручной гейт).
Пер-секреты окружений: токены деплоя, ключи подписи, URL стендов.
Время жизни preview-сред (auto-expire) для контроля стоимости.

6) OIDC-доступ к облакам (без долгоживущих секретов)

Включите `id-token: write`, настройте trust-policy в облаке и используйте временные креденшлы.
Применимо для AWS/Azure/GCP/артефакт-реестров/секрет-менеджеров.
Принцип least privilege: отдельные роли на `dev/stage/prod`.

yaml
- name: Assume cloud role via OIDC uses: your-org/oidc-assume@v1 with:
role: arn:aws:iam::123:role/gha-deploy-prod

7) Релизы, тэги и артефакты

Release по тэгу: changelog, релиз-ассеты, публикация образов/пакетов.
Immutability: тэги «только вперед», подпись контейнеров/чартов.
SBOM (CycloneDX/SPDX) + подпись (cosign/sigstore) — гейт «без подписи — нет деплоя».

8) GitOps и progressive delivery

CD не «из Actions», а через PR/commit в манифест-репо (Argo CD/Flux).
Canary/blue-green: шаги GitOps-бампа веса/версии; авто-промоушен по SLO-метрикам.

yaml
- uses: mikefarah/yq@v4 with:
cmd: yq -i '.image = strenv(IMAGE)' apps/api/values. yaml
- run:
git config user. name "gha-bot"
git commit -am "bump api -> $IMAGE" && git push

9) Безопасность пайплайна и цепочки поставки

Кто может запускать: только из protected branches/tags, с required checks.
Сканирование: SAST/SCA/Secret-scan, DAST на превью-средах.
Подписи: образы, Helm-чарты, бинарники; верификация при деплое.
Политики: диспатчи только из доверенных воркфлоу; pin SHA для сторонних Actions.

10) Наблюдаемость, SLO и ChatOps

Summary отчеты (JUnit/coverage/сканы), статусы в PR.
Метрики: длительность стадий, успех/фейлы, «очередь раннеров».
ChatOps: комментарии бота в PR (ссылки на дашборды, превью-URL), команды `/promote`, `/rollback` через `workflow_dispatch`.

11) FinOps (стоимость минут и ресурсов)

Conccurency-cancel для PR, матрицы только по изменившимся частям (paths-filter).
Гигиена артефактов: `retention-days`, автозакрытие preview env.
Self-hosted пулы для тяжелых сборок/ML, ночные «тихие часы».
Dependency cache и BuildKit GHA-кэш — существенная экономия.

12) Монорепо и Parent/Child-оркестрация

Триггеры по папкам/путям: независимые workflow на компонент.
Reusable как слой стандартизации между командами (Payments/Risk/CRM/ETL/ML).
Разделение секретов/окружений по компонентам.

13) Шаблоны для iGaming

A) Backend/API (Go/Node/Python)

yaml name: backend on: [ pull_request, push ]
jobs:
ci:
uses: your-org/ci-templates/.github/workflows/backend. yml@v3 release:
if: startsWith(github. ref, 'refs/tags/v')
uses: your-org/ci-templates/.github/workflows/release. yml@v3 secrets: inherit

Б) ETL/DBT

yaml name: etl-dbt on: [ pull_request ]
jobs:
dbt:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5 with: { python-version: '3. 11' }
- run: pip install dbt-core dbt-bigquery
- run: dbt deps && dbt run && dbt test
- name: Publish docs run: dbt docs generate && tar czf docs. tgz target/
load artifact, retention period 3 days uses: actions/upload-artifact @ v4 with: {name: dbt-docs, path: docs. tgz, retention-days: 3 }

В) ML/LLM (инференс-артефакты)

yaml name: ml-pack on:
push:
tags: [ "model-" ]
jobs:
build-engine:
runs-on: self-hosted-gpu steps:
- uses: actions/checkout@v4
- run: python export_onnx. py
- run: trtexec --onnx=model. onnx --saveEngine=model. plan
- uses: actions/upload-artifact@v4 with: { name: engine, path: model. plan, retention-days: 7 }
- name: Sign & SBOM uses: your-org/sbom-sign-action@v2 with: { file: model. plan }

14) Чек-лист внедрения

1. Определите шаблоны CI/CD (Reusable/Composite) и примените их к всем репо.
2. Включите Environments с approvals и раздельные секреты.
3. Перейдите на OIDC к облакам/секрет-менеджерам, уберите долговечные ключи.
4. Введите SAST/SCA/Secrets/DAST, SBOM и подпись артефактов; гейты по критическим уязвимостям.
5. Настройте GitOps: манифест-репо, авто-бампы образов/версий, canary/blue-green.
6. Оптимизируйте кэш/матрицы, `concurrency.cancel-in-progress`, очистку артефактов.
7. Разверните self-hosted runner-пулы (в т.ч. GPU) с лимитами и изоляцией.
8. Включите paths-filter и rule-настройки, чтобы не гонять лишние джобы.
9. Добавьте ChatOps: статусы/команды; отчеты в PR.
10. Зафиксируйте политики безопасного использования Actions (pin SHA, ограничить внешние).

15) Антипаттерны

Одинаковые шаги во всех репо вместо Reusable/Composite → рассинхрон стандартов.
Долгоживущие cloud-секреты в переменных вместо OIDC.
Отсутствие Environments/approvals для прод.
Неприджатые версии сторонних Actions → supply-chain риски.
Нет SBOM/подписей → нет верификации на CD.
Всегда-запускающиеся массивные матрицы → рост стоимости.
CD из Actions напрямую в прод без GitOps-трассировки изменений.

Итоги

GitHub Actions позволяет выстроить единый, безопасный и воспроизводимый конвейер релизов: стандартизируйте пайплайны через Reusable/Composite, используйте OIDC и окружения с approvals, внедрите SBOM/подпись, переведите CD на GitOps с progressive delivery, а расходы — под контроль через кэш/матрицы/конкурентность. Такой подход масштабируется под темпы iGaming-продукта, держит качество и снижает операционные риски.