GitHub Actions: Automating Releases

(Section: Technology and Infrastructure)

Brief Summary

GitHub Actions is a native "pipeline as code" in the repository. For iGaming, these are fast and secure releases of backends, frontends, ETL/DBT and ML/LLM services: test matrices, dependency cache, isolated runner pools, Reusable Workflows for uniform standards, OIDC instead of long-lived secrets, signature and SBOM, releases by tags and GitOps-bumps of manifestos. The key is templates and quality/security gates to keep p99 and cost under control.

1) Architectural principles

Pipelines as code ('.github/workflows/.yml'), DRY via Reusable/Composite Actions.
Runner pools: hosted (ubuntu-latest) + self-hosted (K8s/VM, GPU for ML).
Environments: 'dev/stage/prod' with required reviewers, timeouts, and environment secrets.
Policies: protected branches/tags, CODEOWNERS, mandatory checks.
Observability: job summaries, artifacts, logging, duration metrics.

2) Basic template 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

Idea: PR → lint/units → security → by tag 'v' - SBOM/signature and GitOps-bump manifestos for deploy.

3) Reuse: Reusable/Composite

Reusable Workflows: single pipeline templates for all services (in a separate repo '.github').
Composite Actions: gluing repeated steps (lint/units/scans).

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

4) Matrices, cache and performance

`strategy. matrix 'for parallel tests (languages/DB/OS).
Cache: 'actions/cache' for dependencies; BuildKit с `cache-to: gha`; dependency proxies.
Competitiveness: 'concurrency: group: api- $ {{github. ref}}, cancel-in-progress: true '- saves minutes.
Artifacts: store reports/coverage/profiles with 'retention-days'.

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

5) Environments и approvals

Configure required reviewers for 'production' (manual gate).
Environment secrets: deploy tokens, signature keys, URL of stands.
Preview environment lifetime (auto-expire) for cost control.

6) OIDC access to clouds (without long-lived secrets)

Enable 'id-token: write', configure trust-policy in the cloud and use temporary credits.
Applicable for AWS/Azure/GCP/artifact-registers/secret-managers.
The principle of least privilege: individual roles on '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) Releases, tags and artifacts

Release by tag: changelog, release assets, publishing images/packages.
Immunity: "forward only" tags, container/chart signature.
SBOM (CycloneDX/SPDX) + signature (cosign/sigstore) - unsigned gate - no deploy.

8) GitOps и progressive delivery

The CD is not "from Actions," but through PR/commit to a repo manifest (Argo CD/Flux).
Canary/blue-green: weight/version GitOps-bump steps; auto-promotion on SLO metrics.

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) Pipeline and supply chain security

Who can run: only from protected branches/tags, with required checks.
Scanning: SAST/SCA/Secret-scan, DAST on preview environments.
Signatures: images, Helm charts, binaries; verification during depletion.
Politicians: dispatches only from trusted workflows; SHA pin for third-party Actions.

10) Observability, SLO and ChatOps

Summary reports (JUnit/coverage/scans), statuses in PR.
Metrics: stage duration, success/fails, runner queue.
ChatOps: bot comments in PR (links to dashboards, preview URL), commands '/promote ', '/rollback' via 'workflow _ dispatch'.

11) FinOps (cost of minutes and resources)

Concurrency-cancel for PR, matrix only for changed parts (paths-filter).
Hygiene of artifacts: 'retention-days', auto-close preview env.

Self-hosted pools for heavy assemblies/ML, night "quiet hours."

Dependency cache and BuildKit GHA cache are significant savings.

12) Monorepos and Parent/Child orchestration

Folder/path triggers: independent workflows per component.
Reusable as a standardization layer between teams (Payments/Risk/CRM/ETL/ML).
Separation of secrets/environments by components.

13) Templates for 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 }

B) ML/LLM (inference artifacts)

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) Implementation checklist

1. Define CI/CD (Reusable/Composite) templates and apply them to all repos.
2. Include Environments with approvals and split secrets.
3. Go to OIDC to clouds/secret managers, remove durable keys.
4. Enter SAST/SCA/Secrets/DAST, SBOM and artifact signature; critical vulnerability gates.
5. Configure GitOps: manifest-repo, auto-bumps images/versions, canary/blue-green.
6. Optimize cache/matrices, 'concurrency. cancel-in-progress', clearing artifacts.
7. Deploy self-hosted runners (including GPUs) with limits and isolation.
8. Enable paths-filter and rule-settings to avoid driving extra jabs.
9. Add ChatOps: statuses/commands; reports in PR.
10. Fix the Actions secure use policies (pin SHA, restrict external).

15) Antipatterns

The same steps in all repos instead of Reusable/Composite → out of sync standards.
Long-lived cloud secrets in variables instead of OIDC.

Absence of Environments/Approvals for

Uncompressed versions of third-party Actions → supply-chain risks.
No SBOM/signatures → no verification on CD.
Massive matrices that always run → cost increases.
CD from Actions directly to production without GitOps tracing changes.

Summary

GitHub Actions allows you to build a single, secure and reproducible pipeline of releases: standardize pipelines through Reusable/Composite, use OIDC and environments with approvals, implement SBOM/signature, transfer CD to GitOps with progressive delivery, and costs under control through cache/matrices/competitiveness. This approach scales to the pace of the iGaming product, keeps quality and reduces operational risks.