Aller au contenu principal

Mobile Release

Version : 1.0

Statut : Architecture cible

ADR : MOBILE-012

1. Objectif​

Ce document définit la stratégie officielle de livraison (Release Management) de DMV Mobile.

L'objectif n'est pas simplement de publier une application sur les Stores.

L'objectif est de disposer d'une chaîne de livraison :

  • fiable ;
  • reproductible ;
  • sécurisée ;
  • automatisée ;
  • traçable.

Une release doit être un événement maîtrisé, jamais une opération manuelle improvisée.

État actuel​

Les applications web DMV peuvent évoluer et être déployées indépendamment du futur shell mobile. Le shell Capacitor, lui, n'est pas encore identifié comme une application mobile complète dans le code audité.

Architecture cible​

Deux rythmes de release coexistent sans contournement des Stores :

  • une évolution web embarquée correspond à une modification de dmv-public ou dmv-workspace servie par l'infrastructure web existante ;
  • une nouvelle version Capacitor correspond à une modification du shell natif, des permissions, plugins, certificats, icônes, capabilities, deep links ou configurations natives ;
  • toute modification du code exécutable natif ou du bundle embarqué dans l'application soumise doit passer par les circuits Apple App Store et Google Play ;
  • aucune stratégie ne doit télécharger du code exécutable pour contourner la revue Apple ou Google.

Politique de paiement mobile​

Pour le périmètre DMV actuel, les abonnements, boosts et autres droits premium restent vendus hors du shell mobile, via le flux web et Stripe. Le mobile ne doit pas introduire une seconde surface de facturation pour les mêmes droits.

Si une future fonctionnalité mobile devait vendre un contenu ou une fonctionnalité numérique directement dans l'app, elle devrait respecter les règles de Store applicables au moment du développement :

  • sur iOS, Apple impose l'in-app purchase pour débloquer des fonctionnalités, des contenus ou des abonnements numériques dans l'app ;
  • sur Android / Google Play, les achats intégrés sont requis pour les biens et services numériques distribués via Play, sauf programme ou exception explicitement applicable ;
  • les biens physiques et services physiques relèvent d'autres moyens de paiement, mais ce cas n'est pas le modèle DMV actuel ;
  • toute exception de programme ou de région doit être validée au moment du besoin, pas anticipée dans la doc produit.

Dans la doctrine DMV mobile :

  • les achats intégrés ne sont autorisés que pour des consommables numériques à usage limité ;
  • les abonnements numériques, les droits premium permanents et les contenus débloqués durablement restent hors IAP et passent par le web + Stripe ;
  • aucun achat intégré ne doit reproduire ou détourner une offre web existante ;
  • toute future exception doit être explicitement ajoutée à cette section avant implémentation.

Migration​

La migration consiste à séparer clairement :

  1. les déploiements web continus compatibles avec l'application mobile ;
  2. les releases natives nécessitant build, signature, tests et publication Store ;
  3. les changements de configuration serveur qui ne changent pas le code exécutable ;
  4. les règles de compatibilité entre version native minimale et applications web servies.

2. Principes​

La stratégie de release repose sur plusieurs principes.

Une seule branche de production​

La branche main représente toujours l'état de production.

Elle est protégée.

Aucun développement direct n'y est autorisé.

Déploiement continu​

Les développements sont intégrés régulièrement.

Les petites releases sont préférées aux grosses mises à jour.

Automatisation​

Toutes les étapes répétitives doivent être automatisées.

Une intervention humaine augmente le risque d'erreur.

Reproductibilité​

Deux builds réalisés à partir du même commit doivent produire le même résultat.

Traçabilité​

Chaque version publiée doit pouvoir être reliée :

  • à un commit ;
  • à une Pull Request ;
  • à une version API ;
  • à une documentation.

3. Architecture de livraison​

Développeur

↓

Pull Request

↓

CI

↓

Validation

↓

Merge

↓

Build

↓

Signature

↓

Publication

↓

Store

↓

Utilisateur

4. Cycle de vie d'une release​

Une release suit les étapes suivantes.

Développement

↓

Pull Request

↓

Validation automatique

↓

Validation fonctionnelle

↓

Merge

↓

Tag Git

↓

Build Android

↓

Build iOS

↓

Publication interne

↓

Validation

↓

Stores

↓

Déploiement progressif

5. Branches​

La stratégie Git est la suivante.

main

Production

release/*

Préparation d'une version

feature/*

Développements

hotfix/*

Correction urgente

Les branches temporaires sont supprimées après fusion.

6. Intégration Continue (CI)​

Chaque Pull Request déclenche automatiquement :

  • installation des dépendances ;
  • lint ;
  • type checking ;
  • tests unitaires ;
  • build Web ;
  • build Capacitor.

Une Pull Request ne peut pas être fusionnée si un contrôle échoue.

7. Livraison Continue (CD)​

Après validation :

Les builds Android et iOS sont générés automatiquement.

L'objectif est de limiter les manipulations manuelles.

8. Numérotation​

Chaque version possède :

Version fonctionnelle

Exemple :

2.3.0

Version de build

Exemple :

23015

La version fonctionnelle est visible par les utilisateurs.

Le numéro de build est utilisé par les Stores.

9. Signature​

Toutes les applications sont signées.

Android :

Keystore officiel DMV.

iOS :

Certificats Apple.

Les clés privées ne doivent jamais être présentes dans le dépôt Git.

10. Gestion des secrets​

Les secrets sont stockés dans la plateforme CI.

Jamais dans :

  • Git ;
  • le code source ;
  • un fichier de configuration versionné.

Exemples :

  • clés de signature ;
  • certificats ;
  • API Keys ;
  • tokens.

11. TestFlight​

Toute version iOS suit le cycle :

Build

↓

TestFlight

↓

Validation interne

↓

Validation métier

↓

App Store

Aucune version n'est publiée directement.

12. Google Play​

Même philosophie.

Build

↓

Internal Testing

↓

Closed Testing

↓

Open Testing

↓

Production

13. Déploiement progressif​

Les nouvelles versions peuvent être publiées progressivement.

Exemple :

5 %

↓

20 %

↓

50 %

↓

100 %

Cela permet de détecter rapidement une régression.

14. Rollback​

Une version doit toujours pouvoir être retirée.

En cas de problème :

  • arrêt du déploiement ;
  • retour à la version précédente ;
  • analyse.

Le rollback fait partie intégrante de la stratégie de release.

15. Compatibilité​

Une release mobile doit toujours être compatible avec :

  • l'API Laravel supportée ;
  • la version minimale Android ;
  • la version minimale iOS.

Les incompatibilités doivent être anticipées.

16. Notes de version​

Chaque release possède une documentation.

Elle contient notamment :

  • nouveautés ;
  • corrections ;
  • changements techniques ;
  • migrations éventuelles.

Les notes techniques et les notes utilisateurs peuvent être distinctes.

17. Publication​

Une publication n'est autorisée que si :

✓ CI valide

✓ Build valide

✓ Tests validés

✓ Documentation mise à jour

✓ Version API compatible

✓ Signature valide

18. Supervision post-release​

Après une publication :

Les indicateurs suivants sont surveillés :

  • crashs ;
  • performances ;
  • erreurs réseau ;
  • synchronisations ;
  • consommation batterie.

Une hausse anormale peut entraîner un arrêt du déploiement.

19. ADR​

Alternatives étudiées​

Publication entièrement manuelle​

Rejetée.

Trop d'erreurs possibles.

CI uniquement​

Insuffisant.

La génération automatique des builds est également nécessaire.

CI/CD complète​

Retenue.

Elle garantit une chaîne de livraison fiable et reproductible.

20. Décisions figées​

✅ La branche main représente toujours la production.

✅ Toutes les Pull Requests passent par la CI.

✅ Les builds sont reproductibles.

✅ Les applications sont signées.

✅ Les secrets ne sont jamais stockés dans Git.

✅ Les releases sont traçables.

✅ Les déploiements progressifs sont privilégiés.

✅ Le rollback fait partie de la stratégie officielle.

Conclusion​

La stratégie de release de DMV Mobile vise à industrialiser la livraison de l'application.

L'objectif n'est pas simplement de publier une nouvelle version, mais de garantir qu'une mise à jour puisse être produite, validée, déployée et, si nécessaire, retirée de manière fiable et reproductible.

Cette approche réduit les risques, améliore la qualité et assure une évolution maîtrisée de la plateforme mobile.