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-продукту, тримає якість і знижує операційні ризики.