CI/CD bien fait : pipelines Azure DevOps et GitHub Actions pour .NET et Flutter

Un bon pipeline est invisible : les ingénieurs poussent leur code, les tests s'exécutent, un environnement de préproduction se met à jour en quelques minutes et une mise en production est un bouton avec un chemin de retour arrière. Un mauvais pipeline est un rituel du vendredi soir. Voici le schéma que nous installons sur chaque projet — sur Azure DevOps ou GitHub Actions, selon ce qu'utilise votre organisation.

Les cinq étapes

1. Build — restaurer, compiler, produire un artefact versionné une seule fois. Ne jamais recompiler pour une étape ultérieure.
2. Tests — tests unitaires et d'intégration avec couverture ; échec rapide.
3. Analyse — analyse statique (SonarQube), vérification des vulnérabilités des dépendances, détection de secrets.
4. Déploiement en préproduction — automatique sur main, avec tests de fumée et migrations de base de données.
5. Promotion en production — approbation manuelle, blue/green ou swap de slot, retour arrière automatique si les contrôles de santé échouent.

Une API .NET sur GitHub Actions

# .github/workflows/api.yml — build, test, deploy a .NET API to Azure
name: api
on: { push: { branches: [main] } }
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with: { dotnet-version: '9.0.x' }
      - run: dotnet restore
      - run: dotnet build --no-restore -c Release
      - run: dotnet test --no-build -c Release --collect:"XPlat Code Coverage"
      - run: dotnet publish src/Api -c Release -o out
      - uses: azure/webapps-deploy@v3
        with:
          app-name: ishtar-api-prod
          slot-name: staging
          publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
          package: out

Déployer sur un slot de préproduction puis basculer est le détail clé : la nouvelle version se préchauffe, les contrôles de santé passent, et la bascule est instantanée et réversible.

Une application Flutter sur Azure DevOps

Les pipelines mobiles ajoutent la signature et la livraison sur les stores. Nous conservons les secrets (keystores, certificats, clés d'API) dans les fichiers sécurisés et groupes de variables du pipeline — jamais dans le dépôt — et injectons la configuration d'environnement avec --dart-define.

# azure-pipelines.yml — Flutter app build stage
stages:
- stage: Build
  jobs:
  - job: Android
    pool: { vmImage: 'ubuntu-latest' }
    steps:
    - task: FlutterInstall@0
    - script: flutter pub get && flutter test
    - script: flutter build appbundle --release --dart-define=ENV=prod
    - publish: build/app/outputs/bundle/release/app-release.aab
      artifact: android

Une seconde étape envoie le bundle sur la piste interne de Google Play et l'IPA sur TestFlight, de sorte que les testeurs reçoivent automatiquement chaque modification fusionnée.

Infrastructure as code

Les environnements sont définis en Terraform (ou Bicep sur Azure) et appliqués par les mêmes pipelines. Un nouvel environnement — une démo pour un prospect, une région pour un nouveau marché — est une pull request, pas une semaine de clics.

Les pratiques qui font la différence

• Développement sur le tronc avec des branches de courte durée et des revues obligatoires.
• Versionnage sémantique gravé dans l'artefact et affiché dans l'écran « À propos » de l'application.
• Migrations de base de données dans le pipeline, exécutées avant la bascule de l'application, rétrocompatibles sur une version.
• Feature flags pour que déploiement et mise en service soient deux décisions distinctes.
• Portes d'observabilité — un déploiement n'est pas « terminé » tant que les taux d'erreur et la latence ne sont pas sains pendant dix minutes.

Le résultat

Les équipes que nous équipons ainsi livrent en production plusieurs fois par semaine avec moins d'incidents que celles qui livrent chaque mois. Le pipeline n'est pas une surcharge — c'est la fonctionnalité la plus rapide que vous construirez jamais.

Tous les articles