Gestion des Releases et des Patchs
Le cycle de vie binaire dans TkushPatch repose sur deux entités complémentaires :
- La Release de base (
Release) : Le binaire compilé (binaire d'applicationsur Android ouApp.frameworksur iOS) distribué sur le Google Play Store ou l'Apple App Store. Une fois enregistrée, une Release est immuable et verrouillée par son empreintebaseSha256Hash. - Le Patch OTA (
Patch) : Le différentiel binaire compressé (différentiel binaire compressé, fichier.vmcode) calculé par le serveur entre la Release de base du Jour 1 et le nouveau binaire Dart compilé, signé en signature numérique (SHA256withRSA).
1. Registre Maître (/releases) vs Vue Application (/apps/[appId]/releases)
La console propose deux niveaux de lecture :
- Registre Maître (
/releases,src/app/releases/page.tsx) : Vue transverse multi-applications permettant aux équipes Release, Sécurité et SRE de superviser toutes les releases et tous les patchs du tenant, d'enregistrer une nouvelle Release de base (POST /api/admin/v1/releases) ou de soumettre un nouveau Patch (POST /api/admin/v1/patches). - Vue Application (
/apps/[appId]/releases,src/app/apps/[appId]/releases/page.tsx) : Vue dédiée à une seule application avec consolidation multi-ABI.
Consolidation Multi-ABI
Lorsqu'une commande tk-ota-push release android est exécutée sur un App Bundle (.aab), la CLI enregistre automatiquement les binaires de référence pour chaque architecture (aarch64, arm, x86_64). La page /apps/[appId]/releases regroupe ces entrées sous une seule ligne logique (releaseVersion, platform) en affichant les badges d'architectures couvertes (aarch64, armv7, x86_64), le statut Store et le nombre total de patchs rattachés.
2. Vue détaillée d'une Release (/apps/[appId]/releases/[version])
En cliquant sur une version dans /apps/[appId]/releases, l'opérateur accède au dossier complet de cette version (src/app/apps/[appId]/releases/[version]/layout.tsx), structuré en 6 sous-onglets :
| Sous-onglet | Route | Contenu et actions |
|---|---|---|
| 1. Overview | /apps/[appId]/releases/[version] | Chronologie des patchs (#1, #2...), statut (STAGED, APPROVED_AND_SIGNED, ROLLED_BACK), canal, rollout %, pays et actions rapides |
| 2. Insights | /apps/[appId]/insights | Télémétrie filtrée sur cette version : installations réussies, échecs et taux de stabilité |
| 3. Size | /apps/[appId]/releases/[version]/size | Analyse comparative de taille : binaire de base vs taille des patchs .vmcode et gain de bande passante (%) |
| 4. Artifacts | /apps/[appId]/releases/[version]/artifacts | Liste des artefacts physiques par ABI (aarch64, arm, x86_64), hachages SHA-256 (base, pubspec.lock, assets, nativeCodeHash) et téléchargement des .symbols |
| 5. Notes | /apps/[appId]/releases/[version]/notes | Éditeur de notes de version (Release Notes / Changelog) persistées par version (localStorage tks_release_notes_<appId>_<version>) |
| 6. Settings | /apps/[appId]/releases/[version]/settings | Changement du statut Store (LIVE_ON_STORE, IN_STORE_REVIEW, DEPRECATED) via PATCH /api/admin/v1/releases/{id}/status |
3. Actions opérateur sur une Release et ses Patchs
Toutes les actions critiques sont protégées par le composant RoleGuard et journalisées dans la piste d'audit :
États opérationnels d'un patch dans la Console Web
STAGED: Correctif soumis en attente de revue. Non distribué aux utilisateurs.APPROVED_AND_SIGNED: Correctif approuvé par un second intervenant et scellé par signature numérique.ROLLED_BACK: Correctif révoqué suite à une anomalie. Les appareils reviennent sur la version socle.
Tableau des actions disponibles
| Action | Endpoint Backend | Rôles autorisés (roles.ts) | Effet technique |
|---|---|---|---|
| Enregistrer une Release | POST /api/admin/v1/releases | ROLE_ADMIN, ROLE_RELEASE_DEVELOPER | Vérifie le quota Anti-Bomb (maxReleaseSizeMb), calcule le SHA-256, stocke le binaire de base et les .symbols |
| Soumettre un Patch | POST /api/admin/v1/patches | ROLE_ADMIN, ROLE_RELEASE_DEVELOPER | Génère le diff différentiel binaire compressé, vérifie le quota maxPatchSizeMb, place le patch en STAGED (ou APPROVED_AND_SIGNED si auto-signé hors 4-Yeux) |
| Approuver et Signer | POST /api/admin/v1/patches/{id}/approve | ROLE_ADMIN, ROLE_SECURITY_OFFICER | Vérifie la règle des 4-Yeux, signe les 64 caractères ASCII du targetSha256Hash en signature numérique et passe à APPROVED_AND_SIGNED |
| Modifier le Rollout % | PATCH /api/admin/v1/patches/{id}/rollout | ROLE_ADMIN, ROLE_SRE_ADMIN | Ajuste le pourcentage Canary (0% à 100%) et invalide le cache L1/L2 |
| Promouvoir de canal | POST /api/admin/v1/patches/{id}/promote | ROLE_ADMIN, ROLE_SECURITY_OFFICER | Clone le patch APPROVED_AND_SIGNED vers un canal cible (staging, stable) sans recompilation |
| Kill-Switch / Rollback | POST /api/admin/v1/patches/{id}/rollback | ROLE_ADMIN, ROLE_SRE_ADMIN | Passe le statut à ROLLED_BACK, force rolloutPercentage = 0 et ajoute le numéro à rolled_back_patch_numbers |
| Changer statut Release | PATCH /api/admin/v1/releases/{id}/status | ROLE_ADMIN, ROLE_RELEASE_DEVELOPER, ROLE_SRE_ADMIN | Bascule entre LIVE_ON_STORE, IN_STORE_REVIEW (bloque les patchs sur stable) et DEPRECATED (éligible à la purge Day-2) |
Télécharger .symbols | GET /api/admin/v1/releases/{id}/symbols ou /patches/{id}/symbols | ROLE_ADMIN, ROLE_RELEASE_DEVELOPER, ROLE_SRE_ADMIN | Télécharge le fichier DWARF .symbols associé à l'architecture et trace l'action dans l'audit |