☁️ Azure DevOps — Suite ALM & CI/CD (Microsoft)

Les composants (Azure DevOps Services)

Services (cloud) vs Server (on-prem)

Quand Azure DevOps est le meilleur choix ?

RBAC (permissions) — l’armature enterprise

• Permissions au niveau org/projet/repos/pipelines/environments.
• Branch policies (PR) : build obligatoire, reviewers, checks.
• Approvals (environments) : séparation Dev vs Ops vs Security.

Service Connections — le point le plus sensible

Exemples:
- Azure Resource Manager (ARM) / Entra ID Service Principal
- Kubernetes service connection
- Docker registry / ACR
- GitHub connection (si repos externes)
        

• Scopes minimaux (least privilege).
• Rotation des secrets / certificats.
• Audit et ownership clair.

Environments — gates & contrôles

• Associer chaque environnement (DEV/STAGE/PROD) à des checks : approvals, validations, health checks.
• Conserver un historique “qui a approuvé quoi, quand”.
• Aligner avec ton modèle release : canary / blue-green / rolling.

Pratiques qui marchent vraiment

• Backlog propre : épics (macro), features (livrables), stories (valeur), tasks (exécution).
• Definition of Done explicite + checklists (tests, docs, sécurité).
• Capacity/velocity réalistes + limites WIP sur le kanban.
• Templates d’items (ex : “New API endpoint” = checklist auto).

Dashboards & queries

Branching patterns

Monorepo : ne pas déclencher “tout” tout le temps

• Pipelines “path filters” / triggers ciblés.
• CI rapide sur PR, CI exhaustive nightly.
• Cache dépendances + jobs parallèles.

Exemple YAML (Django + tests + artefacts)

trigger:
  branches:
    include:
      - main
      - feature/*

pool:
  vmImage: 'ubuntu-latest'   # ou pool self-hosted

variables:
  PYTHON_VERSION: '3.12'

stages:
- stage: CI
  jobs:
  - job: tests
    steps:
    - task: UsePythonVersion@0
      inputs:
        versionSpec: '$(PYTHON_VERSION)'
    - script: |
        python -m venv venv
        . venv/bin/activate
        pip install -r requirements.txt
        ruff check .
        pytest -q --maxfail=1
      displayName: "Lint + Unit tests"
    - publish: $(System.DefaultWorkingDirectory)
      artifact: "workspace"

- stage: Build
  dependsOn: CI
  jobs:
  - job: package
    steps:
    - script: |
        echo "Build docker image / wheel / zip here"
      displayName: "Package"
        

Templates YAML (standardisation)

# templates/python-ci.yml (concept)
parameters:
  pythonVersion: '3.12'
steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: $
- script: |
    pip install -r requirements.txt
    ruff check .
    pytest -q

# azure-pipelines.yml
steps:
- template: templates/python-ci.yml
  parameters:
    pythonVersion: '3.12'
        

CD patterns (environments + approvals)

Pattern recommandé:
- build un artefact immuable (image Docker / package)
- déployer DEV auto
- smoke tests
- approval STAGE
- approval PROD
- rollback plan (image précédente)
        

• Blue/Green / Canary / Rolling selon ton infra.
• Les gates doivent être “automatisables” (health checks, tests, metrics).

Self-hosted agents : cas d’usage “enterprise”

• Builds avec dépendances lourdes (SDKs, toolchains, licences).
• Accès réseau interne (registry privé, SI fermé).
• Besoin de caches persistants (npm/pip/maven, docker layers).

Stratégie:
- golden image (VM template)
- pool "fast-ci" + pool "heavy"
- autoscaling (si cloud) ou capacity planning (si on-prem)
        

Pools : isoler et router

Cache : le multiplicateur de performance

Caches typiques:
- pip/wheels
- npm/yarn
- maven/gradle
- docker layers (selon stratégie)
Risque:
- cache "sale" => builds non reproductibles
        

Artefacts immuables & promotion

CI -> produit un artefact versionné:
- package (wheel/jar/zip) ou image docker
Puis:
- déploiements DEV/STAGE/PROD consomment le même artefact
        

Supply chain (bonus “enterprise”)

• Scan dépendances avant publication.
• SBOM (CycloneDX/SPDX) pour audit.
• Principe : “build once, deploy many”.

Modèle

Test Plan
  ├─ Test Suite A (feature)
  │    ├─ Test Case 1
  │    └─ Test Case 2
  └─ Test Suite B (regression)
        

Couplage CI

• Publier rapports JUnit + coverage depuis pipelines.
• Associer build number / release à un run de tests.
• Quality gates : bloquer promotion si seuil non atteint.

Secrets : modèle simple et robuste

• Préférer identities (service principal / managed identity) plutôt que tokens “humains”.
• Rotation et expiration systématiques.
• Masquage dans logs + scanning.

Audit

• Historique modifications pipelines/templates.
• Traçabilité approvals.
• Traçabilité releases (build number + git SHA).

Optimisations (fort ROI)

• Pipeline “fast” sur PR : lint + unit tests uniquement.
• Nightly “full” : intégration, e2e, scans security.
• Cache deps et éviter redownload à chaque run.
• Paralléliser par jobs (tests shards).

FinOps

Le coût explose souvent à cause de:
- builds redondants
- pipelines trop lourds sur PR
- manque de cache
- agents sous-dimensionnés (lent = cher)
        

Gates (quality gates) — exemples

Une ligne CV-ready

Mise en place d’une plateforme Azure DevOps (Boards/Repos/Pipelines/Artifacts) avec YAML templates,
branch policies PR, quality gates, agents/pools, et promotion d’artefacts immuables jusqu’à PROD via approvals.
        

Stratégie safe

1. Pilote sur 1–2 repos (non critique).
2. Reproduire CI à l’identique (mêmes tests, mêmes outputs).
3. Mettre templates YAML (standardisation).
4. Branch policies PR (quality gates).
5. Basculer progressivement les triggers / équipes.

Pièges fréquents

• Service connections trop permissives (risque majeur).
• Pipelines “monolithiques” → préférer stages/jobs + templates.
• Builds non déterministes (versions non figées).
• Absence de séparation DEV/STAGE/PROD via environments.

Checklist