Canaux, tracks et support multi-architecture
TkushPatch offre un système puissant de segmentation des flux de livraison (Canaux) combiné à une gestion native et transparente des architectures matérielles (Multi-ABI) pour Android et iOS.
Vue d'ensemble du flux multi-architecture
Dans Flutter, une même version de code source est compilée pour différentes architectures de processeurs :
- Android :
arm64-v8a(appareils modernes 64-bit),armeabi-v7a(appareils 32-bit), etx86_64(émulateurs). - iOS :
arm64(iPhone et iPad).
TkushPatch regroupe ces variantes matérielles sous une même Release Logique (ex: 1.4.0+42). Lors de la distribution, chaque appareil reçoit automatiquement le correctif compilé spécifiquement pour son architecture.
1. Canaux de déploiement (Channels)
Un canal définit la cible opérationnelle d'un patch. Dans la configuration shorebird.yaml ou au moment de l'initialisation, l'application mobile spécifie son canal d'écoute :
| Canal | Environnement cible | Sécurité et gouvernance | Contrôles d'accès |
|---|---|---|---|
staging | Équipes d'assurance qualité (QA), testeurs internes, validation pré-production. | Clé de signature dédiée aux environnements de test. | Filtrage par liste blanche d'appareils QA. |
stable | Utilisateurs finaux en production (Play Store, App Store). | Signature numérique de production. | Déploiement progressif (Canary Rollout) et ciblage géographique. |
custom (ex: beta, vip) | Groupes pilotes, filiales spécifiques, avant-premières. | Clé d'environnement dédiée. | Déploiement ciblé par cohorte ou liste blanche. |
Séparation étanche entre Staging et Production
TkushPatch applique un principe strict de non-contamination entre environnements :
- Isolation des signatures : La signature cryptographique d'un correctif de staging est distincte de celle utilisée en production. Un binaire grand public refusera catégoriquement un patch émis pour un canal interne.
- Promotion contrôlée : Pour pousser un patch de
stagingversstable, l'opérateur exécute une promotion dans la Console Web ou via la CLI. Le correctif est alors scellé avec la signature de production.
2. Tracks de déploiement et alignement avec les Stores
Dans l'écosystème mobile, les applications transitent par des pistes de publication (tracks) auprès d'Apple et Google :
| Piste Magasin (Store Track) | Canal TkushPatch recommandé | Rôle opérationnel |
|---|---|---|
| Google Play Interne / TestFlight | staging | Validation rapide des fonctionnalités par l'équipe QA. |
| Piste Bêta fermée / ouverte | beta (custom) | Test auprès d'une cohorte d'utilisateurs volontaires. |
| Production Publique | stable | Diffusion générale sécurisée avec règles de rollout progressif. |
- Piste interne (Internal Testing) : L'application distribuée via TestFlight ou Google Play Track Interne écoute par défaut sur le canal
staging. Les correctifs sont appliqués lors des sessions de test d'acceptation. - Piste de production (Live Store) : L'application distribuée sur les stores grand public écoute sur le canal
stable. Elle bénéficie des règles de sécurité maximales (4-yeux, déploiement progressif, Store Review Shield).
3. Support Multi-ABI et Multi-Architecture
Pourquoi le Multi-ABI est indispensable
Le framework Flutter compile le code source Dart en instructions machine natives dépendant du processeur de l'appareil. Tenter d'appliquer un différentiel binaire calculé pour une architecture différente provoquerait un plantage immédiat.
TkushPatch prend en charge nativement toutes les architectures cibles de Flutter :
| Plateforme | Architecture (ABI) | Dénomination CLI | Usage principal |
|---|---|---|---|
| Android | arm64-v8a | aarch64 | Plus de 90% des smartphones Android modernes. |
| Android | armeabi-v7a | arm | Terminaux d'entrée de gamme ou appareils plus anciens. |
| Android | x86_64 | x86_64 | Émulateurs Android Studio et appareils spécifiques. |
| iOS | arm64 | aarch64 | Tous les modèles d'iPhone et d'iPad récents. |
4. Regroupement logique et négociation automatique
TkushPatch unifie la complexité matérielle sous le concept de Release Logique :
# Exemple de publication multi-architecture pour une même release
tk-ota-push release --version=1.4.0+42 --platform=android --arch=aarch64
tk-ota-push release --version=1.4.0+42 --platform=android --arch=arm
tk-ota-push release --version=1.4.0+42 --platform=android --arch=x86_64
tk-ota-push release --version=1.4.0+42 --platform=ios --arch=aarch64
Négociation dynamique lors du contrôle de mise à jour
Lorsqu'un terminal mobile vérifie l'existence d'une mise à jour :
- L'application transmet sa version socle, sa plateforme et son architecture processeur.
- Le serveur TkushPatch identifie le correctif actif correspondant exactement à cette architecture.
- Le serveur contrôle les règles de diffusion (taux de déploiement, pays éligibles).
- Le terminal télécharge exclusivement le flux différentiel optimisé pour son processeur.
Ce cloisonnement transparent garantit une exécution fluide et stable sur l'ensemble de votre parc mobile.