⚙️ CircleCI — CI/CD “config.yml”, Workflows, Orbs, Runners

Diagramme CI/CD simple (build → test → deploy)

workflows:
  build_test_deploy:
    jobs:
      - lint
      - unit_tests:
          requires: [lint]
      - build_image:
          requires: [unit_tests]
      - deploy_staging:
          requires: [build_image]
      - hold_prod:
          type: approval
          requires: [deploy_staging]
      - deploy_prod:
          requires: [hold_prod]
        

Modèle “Credits” (lecture rapide)

Le coût est généralement lié à la consommation de compute (classe machine × durée). CircleCI documente l’usage des credits et la vente en packs. :contentReference[oaicite:7]{index=7}

Caches / Workspaces / Artifacts : ne pas confondre

Contexts : secrets “réutilisables” et gouvernance

Pattern:
- Context "org-prod" (secrets prod)
- Context "org-staging"
- Context "org-ci" (tokens read-only)
Attach contexts only to workflows/jobs that need them.
        

• Principe de moindre privilège (least privilege).
• Rotation des secrets + audit des usages.
• Éviter “secrets dans repo” (toujours via env vars/contexts).

Gates & approvals

- job: hold_prod
  type: approval
  requires:
    - deploy_staging
        

Executors (lecture rapide)

Pipeline parameters (config “dynamique”)

version: 2.1

parameters:
  image-tag:
    type: string
    default: "current"

jobs:
  build:
    docker:
      - image: myorg/app:<< pipeline.parameters.image-tag >>
    steps: [checkout]

workflows:
  main:
    jobs: [build]
        

Exemple Django (lint + tests + reports)

version: 2.1

jobs:
  test:
    docker:
      - image: cimg/python:3.12
    steps:
      - checkout
      - run:
          name: Install deps
          command: |
            python -m venv venv
            . venv/bin/activate
            pip install -r requirements.txt
      - run:
          name: Lint + tests
          command: |
            . venv/bin/activate
            ruff check .
            pytest -q --maxfail=1

workflows:
  ci:
    jobs:
      - test
        

Filters (branches/tags) — éviter les builds inutiles

workflows:
  ci:
    jobs:
      - unit_tests:
          filters:
            branches:
              ignore: /release.*/
      - deploy_prod:
          filters:
            tags:
              only: /^v.*/
            branches:
              ignore: /.*/
        

Approval step = gate humain

- hold_prod:
    type: approval
    requires:
      - deploy_staging
- deploy_prod:
    requires:
      - hold_prod
        

Importer un orb

version: 2.1

orbs:
  node: circleci/node@x.y.z

jobs:
  build:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - node/install
      - run: node --version
        

Créer / publier un orb (pattern)

Approche:
- créer des commands réutilisables (setup, build, test, deploy)
- versionner (semver)
- publier dans registry (public/privé)
        

Resource classes = “router” les jobs

# Exemple concept
jobs:
  build_linux_private:
    resource_class: orgname/linux
    steps: ...

  build_macos_private:
    resource_class: orgname/macOS
    steps: ...
        

Best practices runners

• Pool dédié “prod deploy” isolé (réseau + secrets + permissions).
• Golden image + patching + rotation (sécurité).
• Observabilité : logs + métriques machine + queue time.
• Caches/workspaces/artifacts compatibles (FAQ runners). :contentReference[oaicite:19]{index=19}

KPIs indispensables

Quick wins (80/20)

• Pipeline PR “fast” (lint + unit) ; pipeline nightly “full”.
• Paralléliser tests (sharding).
• Cache deps + Docker layers (selon executor).
• Workspaces minimaux (uniquement build outputs).

Une ligne CV-ready

Industrialisation CI/CD sur CircleCI : pipelines as code (.circleci/config.yml), workflows multi-jobs,
standardisation via Orbs, accélération (cache/workspaces), et exécution hybride cloud + self-hosted runners,
avec gates/approvals pour releases PROD et gestion sécurisée des secrets via contexts.
        

Stratégie safe (progressive)

1. Pilote sur 1–2 repos (non critiques) → reproduire CI “à l’identique”.
2. Standardiser très tôt : commands/orbs, conventions (noms jobs, caches).
3. Activer caches + parallélisme + metrics (queue time, duration).
4. Basculer progressivement : triggers, équipes, environnements.
5. Isoler déploiements sensibles sur runners dédiés (VPC/on-prem).

Pièges fréquents

• Cache mal conçu → builds non reproductibles / bugs fantômes.
• Workspaces trop volumineux → pipelines lents.
• Secrets trop “larges” (contexts) → risque majeur.
• Absence d’artefacts immuables → déploiements inconsistants.

Checklist