GitHub Action automazione dei lanci

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

GitHub Action è una linea di montaggio nativa come codice nel repository. Per i , i sono di backend, frontend, ETL/DBT e ML/LLM: matrici di test, cache di dipendenze, runner-pool isolati, Reusable Workflows per standard uniformi, OIDC invece di segreti di lunga durata, firma e SBS OM, comunicati a tag e GitOps-bump manifesti. La chiave sono modelli e gate di qualità/sicurezza per tenere p99 e il costo sotto controllo.

1) Principi architettonici

Pipline come codice ('.github/workflows/.yml'), DRY tramite Reusable/Composite Action.
Runner pool: hosted (ubuntu-latest) + self-hosted (K8s/VM, GPU per ML).
Ambienti (Environments): 'dave/stage/prod'con richired reviewers, timeout e segreti per ambienti.
Criteri: protected branches/tags, CODEOWNERS, controlli obbligatori.
Osservabilità: job summaries, manufatti, logica, metriche di durata.

2) Modello di base 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

L'idea è che le lenti e le unità di sicurezza di V-SBOM/Firma e GitOps-Bump dei manifesti per il deploy.

3) Riutilizzo: Reusable/Composite

Reusable Workflows - Modelli pipeline unici per tutti i servizi (in un repo separato «.github»).
Azioni composite: pendenza dei passaggi ripetuti (lenti/unità/scani).

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

4) Matrici, cache e prestazioni

`strategy. matrix per test paralleli (lingue/database/sistema operativo).
Cache: «action/cache» per le dipendenze; BuildKit с `cache-to: gha`; dependency proxies.
Competitività: 'concorrency: group: api- $ {{github. ref}}, cancel-in-progress: true '- risparmia minuti.
Artefatti - Memorizza report/copertura/profili con «retention-days».

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

5) Environments и approvals

Configurare i richired reviewers per'production '(gate manuale).
Per i segreti degli ambienti: token deploy, chiavi di firma, URL degli stand.
Tempo di vita degli ambienti auto-expire per il controllo dei costi.

6) Accesso OIDC alle nuvole (senza segreti di lunga durata)

Abilita «id-token: write», configura trust-policy nella nuvola e usa le credenziali temporanee.
Applicabile ad AWS/Azure/GCP/manufatti-registro/segreti-manager.
least privilege: ruoli separati sù dave/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) Comunicati, tag e manufatti

Release tag: changelog, release, pubblicazione di immagini/pacchetti.
Immutability: tag «solo avanti», firma contenitori/listini.
SBOM (CycloneDX/SPDX) + firma (cosign/sigstore) - gate «senza firma - nessun deploy».

8) GitOps и progressive delivery

CD non da Action, ma da PR/commit a manifesto repo (Argo CD/Flux).
Canary/blue-green - passi GitOps-bump peso/versione; promozioni auto SLO-metriche.

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) Sicurezza del pipline e catene di fornitura

Chi può eseguire è solo da protected branches/tags, da richired checks.
Scansione: SAST/SCA/Secret-scan, DAST all'avanguardia.
Firme: immagini, elenchi Helm, binari; Verifica in caso di deposito.
Criteri: Display solo da workflow affidabili; pin SHA per le Azioni di terze parti.

10) Osservazione, SLO e ChatOps

Report di summit (JUNnit/coverage/scan), stati in PR.
Metriche: durata degli stadi, successo/feeling, coda runner.
ChatOps: commenti bot in PR (riferimenti a dashboard, anticipo-URL), comandi «/promote », «/rollback» tramite «workflow _ dispatch».

11) FinOps (costo minuti e risorse)

Concurency-cancel per PR, matrici solo per parti modificate (paths-filter).
Igiene degli artefatti: «Retention-days», auto-riparazione preview eng.
Pool Self-hosted per assiemi pesanti/ML, notturni «ore tranquille».
Dipendency cache e BuildKit GHA sono un risparmio significativo.

12) Monorepo e Parent/Child-orchestrazione

Trigger per cartella/percorso: workflow indipendenti per componente.
Reusabile come livello di standardizzazione tra comandi (Payments/Risk/CRM/ETL/ML).
Separare segreti/ambienti per componente.

13) Modelli per il 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 (manufatti infermi)

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) Assegno foglio di implementazione

1. Definite i modelli CI/CD (Reusable/Composite) e applicateli a tutti i repo.
2. Includere Environments con approvals e segreti separati.
3. Vai su OIDC alle nuvole/gestori segreti, rimuovi le chiavi durevole.
4. Inserisci SAST/SCA/Secret/DAST, SBOM e firma manufatti; Gate per vulnerabilità critiche.
5. Configura i GitOps: manifesto-repo, paraurti auto/versione, canary/blue-green.
6. Ottimizza la cache/matrice, 'concertency. cancel-in-progress ', pulizia degli artefatti.
7. Espandere self-hosted runner pool (GPU incluso) con limiti e isolamento.
8. Attivare le impostazioni paths-filter e rule per evitare di correre in eccesso.
9. Aggiungi ChatOps: stati/comandi; rapporti in PR.
10. Fissare i criteri per l'uso sicuro di Azioni (pin SHA, limitare gli esterni).

15) Antipattern

Passo uguale in tutti i repo al posto di Reusable/Composite per il rasincrone standard.
Cloud-segreti a lunga vita nelle variabili invece di OIDC.
Assenza di Environments/approvals per protesi.
Versioni non ridotte di Azioni di terze parti per i rischi supply-chain.
Nessuna firma SBOM, nessuna verifica CD.
Le matrici massicce sempre in esecuzione aumentano i costi.
CD da Action direttamente a provino senza tracciare le modifiche a GitOps.

Riepilogo

Action consente di creare un unico canale di rilascio sicuro e riproduttivo: standardizzare i pipline tramite Reusable/Composite, utilizzare OIDC e gli ambienti con approvals, implementare SBOM/firma, trasferire il CD con progressive delivery e controllare i costi con cache/matrice/competitività. Questo approccio è scalabile al ritmo del prodotto iGaming, mantiene la qualità e riduce i rischi operativi.