Trasportatori CI/CD: GitHub Action, GitLab CI

Trasportatori CI/CD: GitHub Action, GitLab CI

1) Attività CI/CD e posizione nella piattaforma

• Velocità e prevedibilità delle release (breve lead time).
• Qualità (autoveicoli, analisi statica/dinamica).
• Sicurezza della catena di fornitura (firma dei manufatti, controllo della disponibilità).
• Affidabilità (depositi canari, ripristino rapido).
• Osservabilità (traccia e metriche in ogni fase).

I principi chiave sono «pipeline as code», manufatti immutabili, «build once - run many», «shift-left security», «least privacy», assemblaggi determinati.

2) Cartelli architettonici delle linee di montaggio

Stage-gate: build → test → security → package → deploy → post-deploy checks.
Fan-out/Fan-in - Assemblaggi di matrice paralleli (lingue/piattaforme) con l'unione dei risultati.
Promozione - Lo stesso artefatto si sviluppa attraverso l'ambiente (UV) stage prod), invece di essere ricollocato.
Trunk-based + brevi rami: minimizzazione della deriva, controlli automatizzati su PR/MR.
Reusable: workflow/modelli riutilizzati (Action: reusable workflows; GitLab: includes/child-pipelines).
GitOps (opzionale) - Separa «assieme» e «consegna» (Argo CD/Flux monitorano il repo dichiarativo degli ambienti).

3) Sicurezza della catena di fornitura (supply chain)

Identificazione: Federazione OIDC da runner'a cloud (senza chiavi a lunga vita).
I segreti includono storage centralizzato, limitazione del contesto, disattivazione dell'output.
Firma manufatti/contenitori (cosign/Sigstore), verifica della firma nel controllo admissione.
SBOM (CycloneDX/SPDX) e SCA, SAST/DAST/Container Scan - «porta obbligatoria».
Regole: OPA/Conftest per IaC/manifesti, no latest, divieto di contenitori privilegiati.
Isolamento runner'ov: prod runner in una rete privata, separare dall'internet pubblico le disponibilità in uscita.

4) GitHub Action - struttura e pratiche

4. 1 Struttura workflows

`.github/workflows/.yml` — триггеры (`on: push, pull_request, schedule, workflow_call`).
Reusable workflows standardizzato (linter, SCA, contenitore, deposito).

4. 2 Esempio: pipline multiprotocollo con OIDC e firma immagine

yaml name: ci-cd

on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]

permissions:
id-token: write  # для OIDC contents: read packages: write

jobs:
build_test_matrix:
runs-on: ubuntu-latest strategy:
matrix:
node: [18, 20]
os: [ubuntu-latest]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4 with: { node-version: ${{ matrix. node }} }
- name: Cache npm uses: actions/cache@v4 with:
path: ~/.npm key: npm-${{ runner. os }}-${{ matrix. node }}-${{ hashFiles('/package-lock. json') }}
- run: npm ci
- run: npm run lint && npm test -- --ci

docker_build_sign:
runs-on: ubuntu-latest needs: build_test_matrix steps:
- uses: actions/checkout@v4
- name: Login to GHCR uses: docker/login-action@v3 with:
registry: ghcr. io username: ${{ github. actor }}
password: ${{ secrets. GITHUB_TOKEN }}
- name: Build image run:
docker build --pull --no-cache -t ghcr. io/org/app:${{ github. sha }}.
docker push ghcr. io/org/app:${{ github. sha }}
- name: Generate SBOM uses: anchore/syft-action@v0 with:
image: ghcr. io/org/app:${{ github. sha }}
format: cyclonedx-json output-file: sbom. json
- name: Cosign sign (OIDC)
uses: sigstore/cosign-installer@v3
- name: Sign image run:
cosign sign ghcr. io/org/app:${{ github. sha }} \
--yes \
--identity-token $ACTIONS_ID_TOKEN_REQUEST_TOKEN \
--rekor-url https://rekor. sigstore. dev

deploy_stage:
runs-on: ubuntu-latest needs: docker_build_sign environment:
name: stage url: https://stage. example. com steps:
- uses: actions/checkout@v4
- name: Assume cloud role via OIDC uses: aws-actions/configure-aws-credentials@v4 with:
role-to-assume: arn:aws:iam::123456789012:role/github-deployer aws-region: eu-central-1
- name: Helm deploy (canary 10%)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=true --set canary. traffic=10
- name: Smoke checks run:./scripts/smoke. sh

promote_prod:
runs-on: ubuntu-latest needs: deploy_stage environment:
name: production url: https://app. example. com concurrency: prod-release steps:
- name: Manual approval gate run: echo "Requires environment approvers in repo settings"
- name: Promote canary → 100% (blue-green)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=false
- name: Post-deploy checks & rollback on SLO breach run:./scripts/verify_or_rollback. sh

• «permissioni» sono ridotte al minimo, è abilitato «id-token: write» per OIDC.
• Environments con approvers e URL, «concertency» protegge dalle corse.
• Attivazione canaria del traffico e rientro automatico SLO.

4. 3 Reusable workflow (esempio di chiamata)

yaml jobs:
security_suite:
uses: org/.github/.github/workflows/security. yml@v1 with:
severity_threshold: high

5) GitLab CI - struttura e pratiche

5. 1 Struttura base

`.gitlab-ci. yml "alla radice; le entità chiave sono «stage», «jobs», «rule», «needs», «artifacts», «environments», «manual».
Reuse: 'include:' (modelli locali/remote), child/part pipelines per monorepo complessi.

5. 2 Esempio: matrice, cache, firma, ambiente e approvals

yaml stages: [lint, test, build, security, deploy]

variables:
DOCKER_TLS_CERTDIR: "" # docker: dind acceleration
IMAGE_TAG: $CI_COMMIT_SHA

lint:
stage: lint image: node:20 script:
- npm ci
- npm run lint cache:
key: "npm-${CI_COMMIT_REF_SLUG}"
paths: [node_modules/]
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
stage: test image: node:20 parallel:
matrix:
- NODE_VERSION: ["18", "20"]
script:
- nvm install $NODE_VERSION          true
- npm ci
- npm test -- --ci artifacts:
when: always reports:
junit: report. xml

build_image:
stage: build image: docker:26. 1 services: [ "docker:26. 1-dind" ]
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG.
- docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG artifacts:
expire_in: 1 week paths: [ "sbom. json" ]
after_script:
- syft $CI_REGISTRY_IMAGE:$IMAGE_TAG -o cyclonedx-json > sbom. json

security_scans:
stage: security image: alpine:3. 20 script:
- trivy image --exit-code 0 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

deploy_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage url: https://stage. example. com on_stop: stop_stage script:
- kubectl set image deploy/app app=$CI_REGISTRY_IMAGE:$IMAGE_TAG -n stage
-./scripts/smoke. sh needs: [build_image, security_scans]
when: manual allow_failure: false

stop_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage action: stop script:
- kubectl rollout undo deploy/app -n stage

deploy_prod:
stage: deploy image: alpine/k8s:1. 30. 2 environment:
name: production url: https://app. example. com rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual allow_failure: false script:
-./scripts/canary_traffic. sh 10
-./scripts/verify_or_rollback. sh

• `parallel. Matrix simula gli assiemi di matrice.
• «artifacts» + report test.
• Environments con'on _ stop ', manuale à when: manual "per approvals.
• DIND per l'assemblaggio dell'aspetto (meglio se Kaniko/BuildKit nel runner k8s).

5. 3 Child pipelines e include per monorepo

yaml include:
- local:.gitlab/ci/includes/security. yml
- project: org/platform/pipelines file: /k8s/deploy. yml ref: v1

stages: [prepare, component_a, component_b, deploy]

component_a:
stage: component_a trigger:
include:.gitlab/ci/component_a. yml strategy: depend

component_b:
stage: component_b trigger:
include:.gitlab/ci/component_b. yml strategy: depend

6) Monoreposizioni e multiservizi

Directory-based ownership: CODEOWNERS e test scoped per percorso.
Incremental builds - Definiamo i pacchetti o le liste interessate; cache per le chiavi di percorso e i file lock.
Dynamic pipelines: child-pipelines/' workflow _ cal'vengono eseguiti solo per i componenti modificati.
Versioning: semver per ogni modulo, changelog nella fase release.

7) Cache e accelerazione

Cache indirizzi contenuti (hashFiles/lockfile).
Cache separata per dipendenze e artefatti.
Pre-warm runner images (toolchains, SDK).
Mirror locali dei pacchetti (npm/pip/maven) e contenitore registry-cash.

8) Strategie di lancio e ritorno

Canary: aumento graduale della percentuale di traffico; auto-stop in caso di degrado SLO.
Blue-Green: stack paralleli, cambio istantaneo.
Shadow: duplicazione delle richieste senza impatto sul client.
Feature flags: rollout a livello di flag, non di release.
Rollback: script chiari con un pulsante, la versione dell'artefatto è memorizzata nei metadati di rilascio.

9) Infrastrutture e GitOps

IaC: Terraform/Ansibile/Helm sono gestiti in repo separati; policy-as-code come un cancello.
Tracciato GitOps: Argo CD/Flux osservano il repo con i manifesti degli ambienti; la catena di montaggio crea solo un manufatto e aggiorna le versioni in Git.
I vantaggi includono una cronologia chiara delle modifiche ambientali, l'idimpotenza, i rimborsi standard tramite Git.

10) Osservabilità CI/CD

Metriche DORA: frequenza dei deploy, tempo dal commit alla produzione, percentuale di guasti, MTTR.
Telemetry: tempo delle code job 'ov, durata degli stadi, cache hit-rate, frequenza dei test flaky.
I fogli di sicurezza: chi ha lanciato il comunicato, quale porta è stata superata, quali eccezioni sono state rilasciate.

11) Controllo di accesso e approvals

Branch protection e controlli obbligatori.
Environment-approvals - Elenchi di approvers separati per stage/prod.
Accesso JIT per i passaggi manuali, registrazione delle sessioni.
Separazione dei compiti: ruoli diversi per «scrive codice», «approva», «rilascia».

12) Errori frequenti (anti-pattern)

Chiavi cloud a lunga vita nei segreti repo al posto dei ruoli OIDC.
Assembla diversi manufatti per stage e prod (violazione «build once»).
Tag «latest» e immagini mutabili.
Pubblicare i segreti nei fogli dei passi (masking non chiave).
Un pubblico-runner condiviso per i prod-deploy.
Nessun «cancello» di sicurezza (SAST/SCA/Policy) e controlli post-deploy.

13) Assegno foglio di implementazione (0-60 giorni)

0-15 giorni

Configura trunk-based, PR/MR regole, controlli statici obbligatori.
Attivare la Federazione OIDC al cloud minimi «permessi».
Espandere runner's: pubblico per CHI, privato per CD.

16-30 giorni

Aggiungi SBOM, firma immagini nel cluster - Verifica della firma.
Immettere canary/blue-green; auto-rollback SLO.
Cache di dipendenze e artefatti, immagini pre-warm.

31-60 giorni

Separa assieme e consegna (GitOps), policy-as-code cancello.
Installare le metriche DORA e gli alert per il degrado delle pipline.
Modella i pipline (reusable/child) per tutti i servizi.

14) Consigli pratici per l'affidabilità

Supporto di pipline piccole e veloci (10-12 min prima del segnale per PR).
Uccidere i test flaky: quarantine-etichette + fix parallelo.
Non mescolare manufatti CI e release-manufatti; memorizzare i metadati (commit, tempo, SBOM, firme).
Date agli sviluppatori script locali identici ai passaggi della catena di montaggio.

15) Modelli di riutilizzo

15. 1 GitHub Action - security reusable workflow (semplificato)

yaml name: security-suite on:
workflow_call:
inputs:
severity_threshold:
type: string required: false default: high jobs:
sast_sca:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run:./sec/sast. sh --threshold ${{ inputs. severity_threshold }}
- run:./sec/sca. sh --format cyclonedx-json --out sbom. json artifacts: # if using actions/upload-artifact
- sbom. json

15. 2 GitLab - Modello deploy abilitato (semplificato)

yaml
.deployment_template:
image: alpine/k8s:1. 30 script:
- helm upgrade --install $APP charts/$APP --set image. tag=$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

16) Conclusione

GitHub Action e GitLab CI forniscono meccanismi maturi per un ciclo rapido e sicuro di codice →. La chiave del successo è la standardizzazione e la sicurezza: OIDC al posto delle chiavi, firma e SBOM, cancelli di qualità, un unico manufatto con promozione, GitOps e osservabilità tramite DORA. Costruisci le pipline come un prodotto, misurando, semplificando, accelerando, e le release diventeranno una routine, non un evento.