Convoyeurs CI/CD : GitHub Actions, GitLab CI

Convoyeurs CI/CD : GitHub Actions, GitLab CI

1) Tâche CI/CD et place dans la plateforme

• Rapidité et prévisibilité des versions (temps de lecture court).
• Qualité (autotests, analyse statique/dynamique).
• Sécurité de la chaîne d'approvisionnement (signature des artefacts, contrôle des accès).
• Fiabilité (dépliants canaris, retour rapide).
• Observabilité (trace et métriques à chaque étape).

Principes clés : « pipeline comme code », artefacts immutables, « build once - run many », « shift-left security », « least privilège », assemblages déterministes.

2) Modèles architecturaux de convoyeurs

Stage-gate: build → test → security → package → deploy → post-deploy checks.
Fan-out/Fan-in : assemblages matriciels parallèles (langages/plates-formes) combinant les résultats.
Promotion : le même artefact avance à travers les environnements (dev → stage → prod) plutôt que de se recroiser.
Trunk-based + branches courtes : minimisation de la dérive, contrôles automatisés sur PR/MR.
Reusable : workflow/templates surutilisés (Actions : reusable workflows ; GitLab: includes/child-pipelines).
GitOps (en option) : séparation de « building » et de « delivery » (Argo CD/Flux surveillent le repère déclaratif des environnements).

3) Sécurité de la chaîne d'approvisionnement (chaîne d'approvisionnement)

Identification : fédération OIDC de runner 'a au cloud (pas de clés à longue durée de vie).
Secrets : stockage centralisé, limitation du contexte, interdiction de sortie dans les logs.
Signature des objets/conteneurs (cosign/Sigstore), vérification de la signature dans le contrôle d'admission.
SBOM (CycloneDX/SPDX) et SCA, SAST/DAST/Container Scan - « porte obligatoire ».
Politiques : OPA/Conftest pour IaC/manifestes, « no latest », interdiction des conteneurs privilégiés.
Isolation runner's : prod-runners sur un réseau privé, séparer de l'Internet public les accès sortants.

4) GitHub Actions - Structure et pratiques

4. 1 Structure de workflows

`.github/workflows/.yml` — триггеры (`on: push, pull_request, schedule, workflow_call`).
Workflows réutilisables pour la standardisation (linter, SCA, assemblage conteneur, déplay).

4. 2 Exemple : Pipline multi-étapes avec OIDC et signature d'image

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 » est minimisé, « id-token : write » pour l'OIDC est inclus.
• Environnements avec approvers et URL, 'concurrency'protège contre les courses.
• Activation du trafic canarien et retour automatique sur SLO.

4. 3 Flux de travail extensible (exemple d'appel)

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

5) GitLab CI - Structure et pratiques

5. 1 Structure de base

`.gitlab-ci. yml 'à la racine ; entités clés : 'stages', 'jobs', 'rules', 'needs', 'artifacts', 'environments', 'manual'.
Reuse : 'include :' (local/remote templates), child/parent pipelines pour les monoreps complexes.

5. 2 Exemple : matrice, cache, signature, environnement et 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 'imite les assemblages matriciels.
• « artifacts » + rapports de tests.
• Environnements avec 'on _ stop', manuel 'when : manual' pour approvals.
• DIND pour l'assemblage de l'image (mieux - Kaniko/BuildKit dans k8s-runner).

5. 3 pipelines pour enfants et include pour monorépo

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) Monorépositoires et multiservices

Directory-based own....: CODEOWNERS et tests scopés par chemin.
Constructions incrémentales : nous déterminons les paquets/charts touchés ; cache par les clés de chemin et les fichiers lock.
Les pipelines dynamiques : child-pipelines/' workflow _ call 'ne s'exécutent que pour les composants modifiés.
Versioning : semver pour chaque module, changelog à l'étape release.

7) Mise en cache et accélération

Cache d'adresse de contenu (hashFiles/lockfile).
Cache séparé pour les dépendances et les artefacts.
Pre-warm runner images (toolchains, SDK).
Miroirs de paquets locaux (npm/pip/maven) et conteneur registry-cache.

8) Stratégies de sortie et de retour

Canary : augmentation progressive du pourcentage du trafic ; arrêt automatique lors de la dégradation de SLO.
Blue-Green : piles parallèles, commutation instantanée.
Shadow : duplication des demandes sans impact sur le client.
Feature flags : rollout au niveau du drapeau, pas de la sortie.
Rollback : scripts clairs « un bouton », la version de l'artefact est stockée dans les métadonnées de la version.

9) Infrastructure et GitOps

IaC : Terraform/Ansible/Helm sont contrôlés dans des repo distincts ; policy-as-code comme une porte.
Circuit GitOps : Argo CD/Flux observe un repère avec des manifestes d'environnement ; le convoyeur ne fait que créer un artefact et mettre à jour les versions dans Git.
Avantages : historique clair des changements d'environnement, idempotence, retours standard via Git.

10) Observabilité CI/CD

Métriques DORA : taux de déchargements, temps de commit à la production, pourcentage d'échec, MTTR.
Télémétrie : temps des files d'attente job's, durée des étapes, cache hit-rate, fréquence des tests flaky.
Logs de sécurité : qui a initié la libération, quelles portes ont été franchies, quelles exceptions ont été émises.

11) Contrôle d'accès et approvals

Protection Branch et contrôles obligatoires.
Environnement-approvals : listes séparées d'approvers sur stage/prod.
Accès JIT pour les étapes manuelles, le journal des sessions.
Partage des responsabilités : différents rôles pour « écrire le code », « approuver », « libérer ».

12) Erreurs fréquentes (anti-modèles)

Clés cloud à longue durée de vie dans les secrets de repos au lieu des rôles OIDC.
Assemblage de différents artefacts pour stage et prod (violation de « build once »).
'latest' des balises et des images mutables.
Publier des secrets dans les logs d'étape (masking non connecté).
Un général public-runner pour les déployages.
Aucune « porte » de sécurité (SAST/SCA/Policy) et aucun contrôle post-déploiement.

13) Chèque de mise en œuvre (0-60 jours)

0-15 jours

Configurer trunk-based, PR/MR règles, vérifications statiques obligatoires.
Inclure la fédération OIDC dans le nuage ; « permissions » minimales.
Diviser runner's : public - pour CI, privé - pour CD.

16-30 jours

Ajouter SBOM, signature d'image ; dans le cluster - vérification de la signature.
Entrez canary/blue-green ; auto-rollback par SLO.
Cache des dépendances et des artefacts, pre-warm des images.

31-60 jours

Fractionner l'assemblage et la livraison (GitOps), porte policy-as-code.
Établir des métriques DORA et des alertes sur la dégradation des piplines.
Modèle Pipline (reusable/child) pour tous les services.

14) Conseils pratiques sur la fiabilité

Maintenez les petites piplines rapides (10-12 min avant le signal sur PR).
Tuez les tests flaky : quarantine tags + fix parallèle.
Ne mélangez pas les artefacts CI et les artefacts release ; stocker les métadonnées (commit, heure, SBOM, signatures).
Donnez aux développeurs des scripts locaux identiques aux étapes du pipeline (dev-prod parity).

15) Modèles à réutiliser

15. 1 GitHub Actions - security reusable workflow (simplifié)

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 - Modèle deploy inclus (simplifié)

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

GitHub Actions et GitLab CI fournissent des mécanismes matures pour un cycle rapide et sûr "code → prod'. La clé du succès est la normalisation et la sécurité : OIDC au lieu de clés, signature et SBOM, porte de qualité, artefact unique avec promotion, livraison GitOps et observation via DORA. Construisez des piplines comme un produit : mesurez, simplifiez, accélérez - et les sorties deviendront une routine, pas un événement.