Aller au contenu principal

Cycle de vie des releases et des patchs

Dans TkushPatch, la distribution de code en direct sépare clairement le cycle de vie de l'application socle publiée sur les magasins (Release) et celui des correctifs dynamiques diffusés à distance (Patch).

Vue d'ensemble du cycle de déploiement​

Le processus s'articule autour de deux cycles complémentaires :

  • Cycle de la Release Store : Création du binaire ➔ Recette interne ➔ Soumission aux stores (avec protection automatique Store Review Shield) ➔ Publication grand public ➔ Décommissionnement planifié.
  • Cycle d'un Patch OTA : Soumission du correctif ➔ Validation et signature numérique ➔ Recette sur le canal de staging ➔ Promotion vers la production ➔ Déploiement progressif avec ciblage géographique. En cas d'anomalie critique, le Rollback instantané (Kill-Switch) permet de ramener immédiatement les appareils vers la version saine.

1. Cycle de vie d'une Release (ReleaseStatus)​

Une Release correspond à une version compilée de l'application (.apk, .aab, .ipa) distribuée sur les magasins d'applications. Elle évolue selon quatre états principaux :

StatutDescriptionComportement de la plateforme
INTERNAL_TESTINGVersion en cours de recette interne auprès des équipes d'assurance qualité.Les correctifs ciblés sur les canaux internes ou de pré-production sont distribués aux testeurs autorisés.
IN_STORE_REVIEWVersion soumise pour examen aux équipes d'Apple ou de Google.Store Review Shield actif : Les mises à jour dynamiques sont temporairement suspendues sur le canal public pour garantir que les inspecteurs des stores testent le binaire d'origine sans divergence de code.
LIVE_ON_STOREVersion approuvée et disponible publiquement sur les magasins d'applications.Les correctifs validés pour la production peuvent être déployés progressivement auprès de la flotte d'utilisateurs.
DEPRECATEDVersion ancienne décommissionnée au terme de sa période de support.Plus aucun nouveau patch ne peut être rattaché à cette release.

2. Cycle de vie d'un Patch OTA (PatchStatus)​

Un Patch est une mise à jour corrective ciblée sur une release spécifique.

Étape 1 : Soumission du correctif (STAGED)​

Le développeur ou le pipeline d'intégration continue génère le correctif à l'aide de la commande tk-ota-push patch :

  • Le système calcule le différentiel entre le binaire de base de la release et la nouvelle version.
  • Le fichier différentiel est compressé pour réduire la charge réseau à quelques centaines de kilo-octets.
  • Le correctif reçoit un numéro d'ordre incrémental et le statut initial STAGED. Il n'est pas encore distribué aux utilisateurs finaux.
# Exemple de publication d'un patch via la CLI
tk-ota-push patch \
  --app-id=com.entreprise.mobile \
  --release-version=1.4.0+42 \
  --channel=staging

Étape 2 : Validation et signature (APPROVED_AND_SIGNED)​

Pour répondre aux exigences des environnements d'entreprise et bancaires, TkushPatch intègre le principe de double validation (Maker-Checker) :

Règle de séparation des devoirs : L'auteur qui a créé le patch ne peut pas l'approuver pour la production. L'approbation doit obligatoirement être réalisée par un second intervenant habilité (Administrateur ou Release Manager).

Dès l'approbation :

  1. Une empreinte numérique d'intégrité est générée pour sceller le contenu du correctif.
  2. Le patch reçoit une signature cryptographique de production garantissant son authenticité.
  3. Le statut bascule vers APPROVED_AND_SIGNED.

Étape 3 : Recette sur canal Staging​

Avant diffusion publique, le patch est validé sur un canal de pré-production. Pour garantir l'étanchéité des tests, TkushPatch propose une liste d'appareils de test autorisés : seuls les terminaux de l'équipe d'assurance qualité reçoivent le patch sur les canaux internes.

Étape 4 : Promotion vers la Production​

Une fois le correctif certifié conforme :

  1. Le responsable déclenche la Promotion vers le canal de production (stable) depuis la Console Web ou la CLI.
  2. Le patch devient immédiatement disponible pour le déploiement public selon les règles de rollout définies.

3. Déploiement progressif et ciblage géographique​

Afin de maîtriser les risques et de mesurer l'impact de chaque mise à jour, la diffusion d'un patch peut être encadrée avec précision.

Déploiement progressif (Canary Rollout)​

Le pourcentage de diffusion peut être augmenté par paliers successifs (par exemple : 5% ➔ 20% ➔ 50% ➔ 100%) :

  • L'affectation d'un appareil à un palier repose sur un algorithme déterministe utilisant son identifiant unique.
  • Garantie de cohérence : Tout appareil inclus dans une tranche initiale (ex: 5%) restera automatiquement éligible lors de l'extension du palier (20% ou plus). Aucun utilisateur ne subit de retour arrière intempestif.

Filtrage par pays​

TkushPatch permet de restreindre la diffusion d'un correctif à certains pays (codes ISO 3166-1 alpha-2, ex: ["FR", "CI", "SN", "CM"]). Si la localisation d'un terminal ne figure pas dans la liste des territoires ciblés, le patch ne lui est pas proposé.

4. Rollback d'urgence (Kill-Switch)​

En cas d'anomalie critique constatée en production (crash applicatif, anomalie fonctionnelle majeure), TkushPatch permet une désactivation immédiate.

Déroulement de la neutralisation :​

  1. Déclenchement du Rollback : L'administrateur clique sur Rollback dans la Console Web ou utilise la commande CLI tk-ota-push rollback. Le taux de diffusion du patch passe immédiatement à 0% et son statut devient ROLLED_BACK.
  2. Prise en compte par les terminaux : Lors de sa prochaine synchronisation, chaque application mobile détecte que son patch actif est révoqué, le désinstalle localement et repasse automatiquement sur la version saine d'origine.
  3. Suivi dans la Console Web : L'équipe de support peut consulter l'état de la flotte d'appareils, visualiser les terminaux ayant appliqué le rollback et acquitter l'incident une fois la situation résolue.