CI/CD (3/5) : artefacts, registres et environnements

1. Artefacts et versions #

Ce que l'on déploie vraiment.

Un artefact immuable #

L'artefact est le résultat du build : image de conteneur, binaire, paquet (jar, wheel, npm), archive. Il doit être immuable (jamais écrasé), versionné et traçable jusqu'au commit qui l'a produit.

docker build -t registry.example.com/shop/api:${GIT_SHA} \
  --label org.opencontainers.image.revision=${GIT_SHA} \
  --label org.opencontainers.image.source=https://git.example.com/shop/api .
docker push registry.example.com/shop/api:${GIT_SHA}
docker tag registry.example.com/shop/api:${GIT_SHA} registry.example.com/shop/api:1.5.0   # même image, nom de version
docker buildx imagetools inspect registry.example.com/shop/api:1.5.0   # digest

Registres #

Bonne Pratique : Configurez la rétention (supprimer les images de branches après quelques jours, garder les versions publiées) et l'analyse de vulnérabilités du registre.

2. Environnements et promotion #

Du staging à la production.

Promouvoir le même artefact #

Configuration et secrets #

L'artefact ne contient aucune configuration propre à un environnement : URL, tailles, drapeaux et secrets sont injectés au déploiement (variables d'environnement, ConfigMaps, gestionnaire de secrets).

# GitHub Actions : un job lié à un environnement protégé
deploy-prod:
  needs: deploy-staging
  environment: { name: production, url: https://shop.example.com }   # approbateurs, secrets dédiés
  permissions: { id-token: write, contents: read }                   # OIDC
  runs-on: ubuntu-latest
  steps:
    - uses: aws-actions/configure-aws-credentials@v4
      with: { role-to-assume: arn:aws:iam::123456789012:role/deploy-prod, aws-region: eu-west-3 }
    - run: ./deploy.sh production ${{ github.sha }}

Bonne Pratique : Préférez la fédération d'identité OIDC entre la CI et le cloud à des clés d'accès longues stockées en secret : le jeton est temporaire et limité à un dépôt, une branche ou un environnement.

3. Les bases de données #

Le point délicat du déploiement continu.

Migrations versionnées #

Le schéma évolue avec le code, via des migrations versionnées dans le dépôt (Flyway, Liquibase, Alembic, migrations Django ou Rails), appliquées automatiquement par le pipeline avant ou pendant le déploiement.

# Alembic : une migration par changement de schéma, versionnée avec le code
alembic revision -m "ajouter colonne email_verifie"
alembic upgrade head          # exécuté par le pipeline (job dédié ou init container)

Expand / contract #

1. Expand : ajouter la nouvelle colonne, compatible avec l'ancienne version du code.
2. Déployer le code qui écrit dans les deux colonnes et lit la nouvelle.
3. Migrer les données existantes.
4. Contract : supprimer l'ancienne colonne dans une version ultérieure.

Erreur Courante : Une migration destructive (renommage, suppression) dans le même déploiement que le code empêche tout retour arrière et casse les instances encore à l'ancienne version pendant un déploiement progressif.

4. Traçabilité #

Savoir ce qui tourne et pourquoi.

Lier tout ensemble #

• Chaque déploiement est enregistré : version, commit, auteur, date, environnement, résultat.
• Les outils d'observabilité reçoivent un événement de déploiement pour corréler une dégradation avec une version.
• Les notes de version sont générées depuis les commits conventionnels.
• Une SBOM et une signature accompagnent l'artefact (voir la leçon DevSecOps).