Continuous Delivery (CD) : ce que c'est, différence avec Continuous Deployment

Qu'est-ce que Continuous Delivery

Continuous Delivery (CD) est une extension de Continuous Integration qui ajoute de l'automatisation pour toutes les étapes de préparation de version : compilation du build de release, signature avec certificats, obscurcissement, vérification des métadonnées du magasin d'applications et déploiement en staging. Le terme a été introduit par Jez Humble et David Farley dans leur livre « Continuous Delivery » (2010), où ils ont formalisé la pratique qui permet aux équipes de rendre les versions prévisibles et à faible risque.

Évolution de la livraison de logiciels

Avant l'adoption du CD, les versions étaient un événement : l'équipe se réunissait dans une salle, suivait une liste de vérification de 20 points, exécutait des scripts manuellement et espérait que rien ne casse. Continuous Delivery transforme une version d'événement en processus : une petite modification de code peut être livrée aux utilisateurs en quelques minutes, pas en semaines. Amazon, Netflix et Etsy ont été les premiers à adopter le CD dans les années 2010 — aujourd'hui, c'est la norme pour les équipes produit.

Valeur commerciale du CD

La livraison rapide de fonctionnalités est un avantage concurrentiel. Si un concurrent publie de nouvelles fonctionnalités en jours alors que vous prenez des mois, le marché choisit le concurrent. Les métriques DORA montrent : les équipes d'élite (avec CD) ont un délai de déploiement inférieur à 1 heure, les équipes faibles (sans CD) — de 1 semaine à 1 mois. Le CD réduit aussi radicalement le risque : les petites modifications sont plus difficiles à casser qu'une grosse version trimestrielle.

CD vs CI vs Continuous Deployment

Les termes CI, CD et Continuous Deployment sont souvent confondus, mais il existe une frontière claire entre eux. Comprendre les différences aide à concevoir correctement le pipeline et à choisir le niveau d'automatisation qui correspond à la maturité de l'équipe et aux exigences commerciales.

Continuous Integration

CI est le fondement sur lequel le CD est construit. CI garantit que chaque commit passe par la compilation et les tests. Sans CI, le CD est impossible : si le code n'est pas vérifié, il ne peut pas être publié. CI vérifie l'exactitude, le CD vérifie la préparation à l'utilisation commerciale.

Continuous Delivery

Le CD ajoute à CI les étapes de compilation du build de release, de vérification des métadonnées, de signature et de déploiement en staging ou dans le magasin d'applications pour les tests bêta. La différence clé — la décision de publier en production est prise par une personne (manager, product owner). Le CD rend la version « à un clic » — simple et sûre.

Continuous Deployment

Continuous Deployment est une automatisation complète : chaque modification qui passe toutes les étapes du pipeline CD est automatiquement envoyée en production sans approbation manuelle. Continuous Deployment est applicable pour les produits SaaS et les services web, mais est rarement utilisé dans le développement mobile en raison des politiques des magasins d'applications (App Store Review, Google Play Review nécessite une soumission manuelle).

Continuous Delivery pour les applications mobiles

Le CD pour les applications mobiles a des caractéristiques qui le distinguent des pipelines web et backend. Les versions mobiles passent par les magasins d'applications (App Store Review, Google Play Review), ce qui ajoute une barrière de temps et de processus. Le CD automatise tout ce qui peut être automatisé avant la soumission pour examen afin de maximiser les chances de passer la vérification du premier coup.

Préparation pour la publication sur Google Play

Le pipeline CD Android comprend : la compilation de l'AAB (Android App Bundle), la signature avec une clé de release, l'obscurcissement via R8/ProGuard, la vérification de la taille de l'APK et des classes multidex, la génération des notes de version. L'utilisation des product flavors Gradle (free/paid, dev/staging/prod) permet de gérer plusieurs configurations à partir d'un seul pipeline.

Préparation pour la publication sur l'App Store

Le CD iOS nécessite la signature avec des certificats via Fastlane match, la vérification de la conformité des icônes (exigence de l'App Store — 1024×1024 px), la validation des métadonnées (nom, description, mots-clés), la vérification de l'absence d'API privées. La validation technique est effectuée via altool --validate-app sans téléchargement vers App Store Connect, ce qui fournit un retour rapide.

# Fastfile — pipeline CD complet pour iOS et Android
platform :ios do
  desc "CD iOS — préparation de la version et téléchargement vers TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "CD Android — compilation AAB et téléchargement vers Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight collecte les captures d'écran, obtient les certificats via match, compile l'IPA et le télécharge vers TestFlight. La lane deliver_to_internal pour Android compile Release AAB via Gradle et le télécharge vers la piste interne de Google Play Console. Les deux pipelines sont exécutés depuis CI après la réussite des tests.

Composants du pipeline CD

Un pipeline CD se compose d'étapes séquentielles, chacune ajoutant la confiance que la version est prête pour les utilisateurs. Les étapes sont divisées en techniques (compilation, signature) et produit (métadonnées, captures d'écran, vérification des descriptions). Sauter une étape augmente le risque que la version soit rejetée par le magasin d'applications.

Gestion des versions

Un composant critique du CD est la gestion automatique des versions. L'incrémentation de version (versionCode et versionName pour Android, CFBundleVersion et CFBundleShortVersionString pour iOS) est effectuée sur la base des tags Git ou de la version précédente dans le magasin. Fastlane increment_version_number et les commandes Gradle (versionCode auto-increment) automatisent cette étape.

Métadonnées du magasin

Google Play Console et App Store Connect exigent : description de l'application, mots-clés, catégorie, évaluation, liens vers la politique de confidentialité. Le CD inclut la vérification de la présence et de l'exactitude des métadonnées. Fastlane deliver et supply automatisent le téléchargement des descriptions, captures d'écran et icônes avec le build.

Vérifications de passerelle

Avant de soumettre pour examen, le pipeline effectue des vérifications de passerelle : vérification de la taille du build (APK > 200 Mo est rejeté par Google Play), présence de toutes les localisations, absence de symboles de débogage dans le build de release, vérification du fichier de mapping ProGuard pour décoder les logs de crash. Si une vérification échoue — le pipeline bloque la version.

Tests automatisés pour le CD

Le niveau de confiance dans le CD est directement proportionnel à la qualité des tests automatisés. Si les tests ne détectent pas les régressions — la version peut casser la production et l'équipe perd confiance dans le CD. Le CD mobile nécessite une pyramide de tests à trois niveaux adaptée aux spécificités de la plateforme.

Tests unitaires

Les tests unitaires vérifient la logique métier de manière isolée. La couverture de code doit être d'au moins 70 % pour les modules critiques (authentification, paiements, réseau). CI exécute les tests unitaires à chaque push, et s'ils échouent — le pipeline CD est bloqué jusqu'à la correction.

Tests d'intégration

Ils vérifient l'interaction des composants : couche réseau avec API réelle (ou serveur mock), base de données, système de fichiers. Les tests Room DAO pour Android, les tests Core Data pour iOS sont des exemples de tests d'intégration. Ils sont plus lents que les tests unitaires (1 à 5 minutes) et sont exécutés à l'étape CD, pas dans CI à chaque commit.

Tests d'interface utilisateur et de captures d'écran

Les tests de captures d'écran (snapshot testing) comparent les écrans de l'application avec des images de référence. Si une modification de code a changé l'interface utilisateur — le test échoue et le développeur vérifie si la modification est attendue. Android supporte Roborazzi et Paparazzi, iOS — SnapshotTesting par Point-Free. Les tests de captures d'écran sont exécutés avant la publication dans le cadre du pipeline CD.

Meilleures pratiques de Continuous Delivery

La mise en œuvre de Continuous Delivery nécessite non seulement des outils mais aussi un changement de culture d'équipe. Les pratiques ci-dessous sont basées sur des années d'expérience d'équipes mobiles de Google, Spotify et Uber et sont adaptées à des projets de toute taille.

Feature Flags

Le code d'une nouvelle fonctionnalité est livré en production mais caché derrière un flag. Les Feature flags permettent de déployer du code avant que la fonctionnalité ne soit prête pour les utilisateurs et de la désactiver instantanément en cas de problème. Bibliothèques : LaunchDarkly, Firebase Remote Config, Unleash. Les Feature flags sont une exigence obligatoire pour le CD dans les projets mobiles.

Environnement de staging

Avant la livraison en production, le build est déployé en staging — un environnement identique à la production mais avec des données de test. Les ingénieurs QA vérifient la fonctionnalité sur un build de staging installé via TestFlight ou la piste Internal Testing. Si le staging passe — le build reçoit l'approbation pour soumission à l'examen du magasin.

Notes de version et changelog

Le CD génère automatiquement des notes de version basées sur les messages de commit. Les Conventional Commits (feat:, fix:, chore:) et les tags Git au format de versionnement sémantique permettent d'analyser l'historique des modifications. Fastlane changelog_from_git_commits collecte les modifications entre les deux derniers tags et les formate pour le magasin d'applications.

Surveillance post-publication

Le CD ne s'arrête pas à la publication — après la version, la surveillance commence : taux de crash, taux d'ANR pour Android, temps de démarrage, taux d'échec des paiements. Si les métriques dépassent les limites normales — le pipeline CD doit automatiquement annuler la version ou notifier l'équipe. Outils : Firebase Crashlytics, Sentry, New Relic.

// Exemple de Feature Flag avec Firebase Remote Config pour CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// Utilisation dans le code
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}