CI/CD conducte: Acțiuni GitHub, CI GitLab

CI/CD conducte: Acțiuni GitHub, CI GitLab

1) Sarcină CI/CD și spațiu de platformă

• Viteza și predictibilitatea lansărilor (timp scurt de plumb).
• Calitate (teste auto, analiză statică/dinamică).
• Securitatea lanțului de aprovizionare (semnarea artefactelor, controlul accesului).
• Fiabilitate (depozite canare, rollback rapid).
• Observabilitate (urme și valori în fiecare etapă).

Principii cheie: „conductă ca cod”, artefacte imuabile „, construi o dată - a alerga multe”, „schimbare-stânga de securitate”, „privilegiu de stânga”, ansambluri deterministe.

2) Modele arhitecturale de transportoare

Etapa-poarta: construi test securitate pachet implementa verificări post-implementare.
Fan-out/Fan-in: ansambluri de matrice paralele (limbi/platforme) cu concatenarea rezultatelor.
Promovarea: același artefact este promovat prin mediu (dev → etapa → prod), și nu reasamblate.

Pe bază de trunchi + ramuri scurte: minimizare drift, verificări automate pe PR/MR

Reutilizabil: fluxuri de lucru reutilizabile GitLab: include/conducte pentru copii).
GitOps (opţional): separarea mediilor „asamblare” şi „livrare” (mediile declarative repo ale monitorului Argo CD/Flux).

3) Securitatea lanțului de aprovizionare

Identificare: federația OIDC de la alergător la nor (fără chei de lungă durată).
Secrete: stocare centralizată, restricționarea contextului, interzicerea exploatării forestiere.
Semnătura artefactelor/containerelor (cosign/Sigstore), verificarea semnăturii în controlul admiterii.
SBOM (CycloneDX/SPDX) și SCA, SAST/DAST/Container Scan - „poarta obligatorie”.
Politicieni: OPA/Conftest pentru IaC/manifeste, „nu mai târziu”, interzicerea containerelor privilegiate.
Izolarea alergătorilor: alergători prod într-o rețea privată, acces separat la ieșire de la internetul public.

4) Acțiunile GitHub - Structură și practici

4. 1 structură de fluxuri de lucru

'.github/workflows/.yml' - триггеры (' on: push, pull_request, program, workflow_call').
Fluxuri de lucru reutilizabile pentru standardizare (linter, SCA, asamblare containere, implementare).

4. 2 Exemplu: conductă în mai multe etape cu OIDC și semnătură imagine

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

• "permissions" sunt minimizate, "id-token: write 'is enabled for OIDC.
• Medii cu aprobatori și URL, „concurență” protejează împotriva curselor.
• Includerea canară a traficului și revenirea automată peste SLO.

4. 3 Flux de lucru reutilizabil (exemplu de apel)

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

5) GitLab CI - Structura și practicile

5. 1 Structura de bază

'.gitlab-ci. yml' la rădăcină; entități cheie: „etape”, „locuri de muncă”, „reguli”, „nevoi”, „artefacte”, „medii”, „manual”.
Reutilizare: „include:” (modele locale/de la distanță), conducte pentru copii/părinți pentru monorepos complexe.

5. 2 Exemplu: matrice, memorie cache, semnătură, medii și aprobări

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

• "paralel. matrice "simulează ansambluri matrice.
• „rapoarte de testare” +.
• Medii cu 'on _ stop', manual 'când: manual' pentru aprobări.
• DIND pentru construirea unei imagini (mai bine - Kaniko/BuildKit în k8s runner).

5. 3 Conducte pentru copii și includ pentru monorepos

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) Monorepozitor și multiservice

Proprietatea pe bază de directoare: CODEOWNERS și teste pe cale.
Incremental construiește: identifică pachetele/diagramele afectate; cache prin cheile de cale și fișiere de blocare.
Conducte dinamice: conducte pentru copii/' workflow _ call' rulează numai pentru componente schimbate.
Versioning: semver pentru fiecare modul, changelog la etapa de eliberare.

7) Caching și accelerare

Content address caches (hashFiles/lockfile).
Cache separat pentru dependențe și artefacte.
Pre-cald runner imagini (lanțuri de instrumente, SDK).
Oglinzi locale pentru pachete (npm/pip/maven) și memoria cache pentru registrul containerelor.

8) Strategii de lansare și rollback

Canare: creșterea treptată a procentului de trafic; auto-stop în timpul degradării SLO.
Albastru-verde: stive paralele, comutare instantanee.
Shadow: cereri duplicate fără a afecta clientul.
Caracteristică steaguri: rollout la nivel de pavilion, nu nivel de eliberare.
Rollback: ștergeți scripturile cu un singur buton, versiunea artefact este stocată în metadatele de eliberare.

9) Infrastructură și GitOps

IaC: Terraform/Ansible/Helm sunt gestionate în repo separate; policy-as-code as a gate.
GitOps-contur: Argo CD/Flux observa repo cu manifeste de medii; conducta creează doar un artefact și actualizează versiunile în Git.
Avantaje: istorie clară a schimbărilor de mediu, idempotență, rollback-uri standard prin Git.

10) Observabilitatea CI/CD

DORA: rata de epuizare, timpul de la angajament la producție, rata de eșec, MTTR.
Telemetrie: timpul de cozi de locuri de muncă, durata etapelor, rata de lovire a memoriei cache, frecvența testelor fulgi.
Jurnalele de securitate: cine a inițiat eliberarea, care porți au fost trecute, care excepții au fost emise.

11) Controlul accesului și aprobări

Protecția sucursalelor și controalele obligatorii.
Aprobări de mediu: liste de aprobatori separate pe scenă/prod.
Acces JIT pentru pași manuali, logare sesiune.
Separarea sarcinilor: roluri diferite pentru „scrie cod”, „aprobă”, „eliberează”.

12) Erori frecvente (anti-modele)

Chei nor de lungă durată în secretele repo în loc de roluri OIDC.
Asamblarea diferitelor artefacte pentru etapa și prod (încălcarea „construi o dată”).
etichete „latest” și imagini mutabile.
Publicarea secretelor în jurnalele pas (non-dezactivat mascare).
Un alergător public comun pentru implementarea producției.
Lipsa „porților” de securitate (SAST/SCA/Policy) și verificările post-implementare.

13) Lista de verificare a implementării (0-60 zile)

0-15 zile

Configurați reguli bazate pe portbagaj, PR/MR, verificări statice obligatorii.
Activați federația OIDC în cloud; minimal 'permissions'.
Post-alergători: public - pentru CI, privat - pentru CD.

16-30 zile

Adăugați SBOM, semnătura imaginii; Cluster - Verificarea semnăturii.
Introduceți canar/albastru-verde; auto-rollback de SLO.
Cache de dependențe și artefacte, imagini pre-calde.

31-60 zile

Asamblare și livrare separată (GitOps), poartă de politică ca cod.
Stabilirea măsurătorilor și alertelor DORA pentru degradarea conductelor.
Șabloane conducte (reutilizabile/copil) pentru toate serviciile.

14) Sfaturi practice de fiabilitate

Suport conducte mici, rapide (10-12 minute înainte de semnalul de PR).
Kill teste flaky: etichete de carantină + fix paralel.
Nu amestecați artefacte CI și eliberați artefacte; stoca metadate (comite, timp, SBOM, semnături).
Oferiți dezvoltatorilor scripturi locale identice cu pașii conductei (paritatea dev-prod).

15) Șabloane pentru reutilizare

15. 1 Acţiuni GitHub - flux de lucru reutilizabil pentru securitate (simplificat)

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 - include implementare șablon (simplificat)

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) Concluzie

Acțiunile GitHub și CI GitLab oferă mecanisme mature pentru o buclă rapidă și sigură de cod → prod. Cheia succesului este standardizarea și securitatea: OIDC în loc de chei, semnătură și SBOM, porți de calitate, un singur artefact cu promovare, livrare GitOps și observabilitate prin DORA. Construiți conducte ca produs: Măsurați, simplificați, accelerați - iar eliberările vor deveni o corvoadă, nu un eveniment.