Un bug critique de paiement est déployé à 2 heures du matin le vendredi. Au moment de la réunion matinale, les dirigeants veulent un plan de récupération, mais la correction est en attente d'une revue de l'application. Le serveur de backend est en bonne santé, le CDN sert du contenu et l'équipe d'ingénierie a un correctif testé. Les utilisateurs ne peuvent toujours pas terminer l'opération qu'ils ont ouverte l'application pour effectuer.
Cet incident révèle le sens de disponibilité de l'applicationElle ne se limite pas à savoir si une liste existe dans un magasin ou si les serveurs répondent aux contrôles de santé. La disponibilité dépend de savoir si les bons utilisateurs peuvent atteindre une version fonctionnelle, terminer la tâche principale et se rétablir rapidement lorsqu'une mise à jour ou une dépendance faille. La revue de magasin, la distribution étape par étape, le comportement en temps de cours, la livraison réseau, les contrôles de conformité et la sécurité de retraitement contribuent tous à l'issue.
Sommaire
- Qu'est-ce que la disponibilité réelle d'une application signifie
- Pourquoi les applications s'éteignent-elles d'abord
- Les choix d'architecture qui améliorent la disponibilité
- Surveillance, MTTR et MTBF en pratique
- Stockage des mises à jour versus mises à jour par voie aérienne
- Lancements, annulations et livraison en temps réel
- Contraintes de sécurité et de conformité sur la disponibilité
- Liste de contrôle de disponibilité pratique et questions fréquentes
context:Page/area: Appflow comparison / migration marketing copy. Role: Section or page heading. Seen in: page ionic-appflow.astro. Message key `appflow_faq_title` (Appflow FAQ Title)
Qu'est-ce que la disponibilité réelle d'une application
Quatre indicateurs rendent la promesse mesurable
Disponibilité context : Page/zone : Section des logos des clients / preuves sociales. Rôle : Étiquette de l'IHM. Vue dans : composant Hero.astro, composant companies-logo.astro. Clé de message `companies_logo_stat_uptime_label` (Étiquette des statistiques des logos des entreprises pour la disponibilité). est la mesure de tête, mais elle peut cacher une panne partielle. Un processus peut répondre aux sondes tout en laissant aux utilisateurs des paiements échoués, des écrans vides ou des menus inutilisables. Associez la disponibilité àtaux de consommation de budget d'erreur
qui montre à quel rythme une incident consomme le forfait de panne associé à votre cible d'accessibilité interne. Uncontrat de niveau de service ou SLA, transforme la cible en promesse. Les équipes expriment souvent cette promesse sous forme d'un objectif mensuel d'accessibilité tel que99,9 % ou 99,99 %
mais le nombre seul ne définit pas l'expérience utilisateur. Vous avez également besoin de règles claires pour déterminer quelles transactions comptent comme une transaction indisponible, lesquelles régions sont incluses et comment la dégradation de la fonctionnalité est mesurée.temps moyen de récupération après panne (MTTR) : mesure le temps entre la détection d'une panne et le rétablissement du service ou de la flux utilisateur affecté. Il comprend le diagnostic, l'approbation de la mise à jour, la propagation et la vérification, et non seulement le temps que passe le développeur à modifier code. MTBFLa durée moyenne entre les pannes, qui mesure la fréquence des pannes au cours de la période d'exploitation.
Règle pratique : Suivez la disponibilité au niveau du parcours utilisateur principal, puis utilisez la disponibilité de l'infrastructure comme preuve complémentaire.
La fiabilité et les performances sont liées mais distinctes. La fiabilité demande si le système continue à se comporter correctement au fil du temps. Les performances demandent à quelle vitesse il répond. Une application qui charge lentement est dégradée, tandis qu'une application qui plante à l'ouverture ou qui ne peut pas soumettre un achat est indisponible pour cet utilisateur.
Pour une vue opérationnelle plus large, associez ces mesures aux pratiques de surveillance de la santé de l'application . La clé est de considérer la disponibilité comme un problème SLA probabiliste. Une mise à jour peut passer la revue et les tests normaux, mais son véritable fenêtre de livraison dépend de la volatilité de la file d'attente, des contrôles de déploiement, des conditions des appareils, de la géographie et du temps nécessaire pour émettre une correction sécurisée. Pourquoi les applications s'éteignent-elles en premier lieuLa plupart des pannes mobiles et de bureau se répartissent en trois familles. Chacune a un symptôme, un modèle de détection et un canal de récupération différents, donc un seul tableau de bord de disponibilité ne dira pas auquipe ce qu'il faut faire ensuite.
MTBF
La durée moyenne entre les pannes, qui mesure la fréquence des pannes au cours de la période d'exploitation.
Échecs de mise en magasin
La première famille existe avant que le binaire ne parvienne aux utilisateurs. Une soumission iOS peut être rejetée ou retardée pendant la revue. Un package Android peut être supprimé après une violation de politique. Une mise en production déphasée peut s'arrêter d'expansion après des signaux de panne s'aggravent. Dans chaque cas, l'ingénierie peut avoir une construction valide, mais les contrôles de distribution déterminent qui peut l'installer.
La taille d'Apple rend ce problème une question de plateforme plutôt qu'un cas d'extrémité. En 2024, son équipe de revue d'applications a examiné environ 7,77 millions de soumissions et a rejeté environ 1,93 million, tandis que environ 295,000 ont été approuvés plus tard après des corrections. Apple a également supprimé plus de 82 000 applications après avoir identifié des violations post-lancement, comme le rapporté dans les données de rejet d'Apple App Store. Le symptôme visible est souvent une ancienne version restant sur le terrain, tandis que le canal de récupération est une soumission de magasin corrigée.
Échecs de runtime
Les échecs de runtime commencent après l'installation. Les régressions de mémoire native peuvent provoquer un plantage au lancement. Un bundle JavaScript peut échouer après une mise en production précipitée. Un lien profond endommagé peut laisser les utilisateurs coincés sur une écran non valide, et une modification de la mise en cache de certificats peut rejeter les demandes légitimes sur les clients plus anciens.
Délais de détection allant de la télémétrie de plantage immédiate aux formulaires de support retardés. Le chemin de récupération dépend de la couche échouant. Les défauts natifs nécessitent généralement un nouveau fichier binaire de magasin, tandis que les défauts JavaScript, de configuration, de copie et d'actifs peuvent être corrigés à l'aide d'un canal de mise à jour en direct contrôlée si l'architecture de l'application le permet.
Échecs de réseau et d'edge
La troisième famille comprend les erreurs de CDN, les erreurs de migration DNS, la limitation régionale API et les échecs de handshake TLS sur les systèmes d'exploitation plus anciens. Ces incidents peuvent affecter uniquement une géographie ou un groupe de dispositifs, ce qui fait que la disponibilité globale semble saine tandis qu'une audience significative ne peut pas poursuivre.
| Famille de la cause | Exemple typique | Délai de détection | Canal de récupération |
|---|---|---|---|
| Contrôle de magasin | Rejet de la revue ou approbation retardée | État de soumission ou rapports de l'utilisateur | Soumission et réponse de politique de magasin corrigés |
| Crash de runtime | Bundle, lien profond ou régression native cassé | Analyse de crash, échecs de session, support | Rollback, mise à jour en direct, changement de configuration ou nouvelle version binaire |
| Réseau et bordure | Échec régional API, CDN, DNS ou TLS | Probes synthétiques et surveillance utilisateur réelle | Déplacement de trafic, récupération de dépendance, correction de bordure ou redondance client |
La voie de récupération la plus lente détermine le résultat pratique de disponibilité. Les conseils de revue de magasin indiquent que 90% des soumissions sont examinées en moins de 24 heuresmais les rapports independants décrit des retards plus longs pendant les périodes de pointe et pour les applications de premier temps ou les mises à jour majeures, parfois atteignant 24 à 48 heures ou au-delà de 72 heures. Le analyse du temps de revue de l'application m'importe car une correction peut être techniquement prête tandis que les utilisateurs restent exposés.
Choix d'architecture qui améliorent la disponibilité
La disponibilité s'améliore lorsque le système a moins de points de failure uniques et plus de façons de servir une réponse utile lors de problèmes de dépendance. Commencez par les changements qui réduisent le rayon d'explosion évident, puis ajoutez des contrôles qui préserver les workflows de base sous stress.
Enlever les hypothèses locales en premier
Exécutez serveurs d'applications sans état derrière un équilibreur de charge. Stockez les sessions et les états durables dans des services partagés plutôt qu'en un seul instance, afin que le trafic puisse se déplacer lorsque un processus ou une zone fail. Ajoutez des contrôles de santé qui distinguent la vivacité de la disponibilité. Un processus en vie peut toujours être incapable de servir le trafic car sa pool de base de données est épuisé ou une dépendance requise est en train de fail.
La redondance active-active à travers les régions supprime la dépendance à une copie en vie. Utilisez un DNS pondéré ou un équilibreur de charge global pour déplacer le trafic, mais testez le chemin de failover plutôt que de considérer la configuration comme une preuve. Les pairs de région doivent être séparés suffisamment pour réduire les échecs corrélés, avec la place exacte déterminée par les exigences de latence, légales et de cohérence des données.
Préservez les dépendances pour qu'elles ne prennent pas l'application avec elles
Placez des interrupteurs de circuit autour des services externes. Définissez des temps limites explicites, fixez le nombre de réessais et renvoyez une réponse utile lorsque le fournisseur est lent. Une vue de lecture en cache peut préserver la navigation pendant que les écritures attendent. Un drapeau de fonctionnalité peut désactiver les recommandations sans désactiver le paiement. Une file d'attente locale peut conserver les opérations d'écriture éligibles jusqu'à ce que le réseau revienne, à condition que le produit puisse expliquer l'état en attente de manière sûre.
Une dépendance devrait être autorisée à échouer sans forcer l'ensemble du parcours utilisateur à échouer.
Le chaos ingénierie transforme ces hypothèses en preuves. Organisez des jours de jeu qui terminent les pods, isolez une région, épuisez une dépendance et exercez la voie de retrait. Le résultat précieux n'est pas un rapport de panne dramatique. C'est savoir quel avertissement se déclenche, qui prend la décision, comment le trafic se déplace et si le client peut toujours effectuer sa tâche de base.
Les équipes travaillant sur les modèles de résilience régionale peuvent utiliser ceci guide de déploiement multi-région comme point de référence. La conception de l'architecture établit un niveau de disponibilité de base, mais elle ne peut pas supprimer les files d'attente de magasin ou faire disparaître une mise à jour client non sûre. Les contrôles de distribution nécessitent toujours leur propre conception.
Surveillance, MTTR et MTBF en pratique
Un programme de disponibilité mature combine trois vues de la même expérience utilisateur. Les sondes synthétiques exécutent des parcours scriptés à un horaire la surveillance des utilisateurs réels captures ce que les clients installés expérimentent, et analyse des crashes identifie les échecs de stabilité par version de sortie, plateforme, appareil et cohorte.
Les vérifications synthétiques répondent à la question de savoir si un chemin connu fonctionne à partir de localisations sélectionnées. Les données de l'utilisateur réel révèlent les échecs que la couverture synthétique manque, comme une version spécifique d'un système d'exploitation ou une condition de réseau régionale. L'analyse des crashes montre si une nouvelle version a changé la stabilité du client, mais les équipes devraient l'associer à la latence de backend et aux erreurs de transaction plutôt que de traiter les crashes comme l'histoire entière.
Alerte sur le changement, pas le bruit
Les comptes d'erreurs absolus créent des alertes faibles pour les systèmes importants et manquent les changements significatifs dans les petites cohorts. Utilisez les deltas de taux d'erreur par rapport à un référentiel récent, puis séparez les pages par gravité. Une erreur de paiement devrait alerter le principal de la rotation de secours même si le taux d'erreur global de l'application reste bas. Une fonctionnalité cosmétique peut créer un ticket à la place.
Les alertes de taux de débit fournissent une vue opérationnelle de la SLA. Utilisez une fenêtre rapide pour une détection urgente et une fenêtre plus lente pour une confirmation, en suivant le principe de plusieurs fenêtres utilisé dans la pratique SRE. Les seuils exacts devraient refléter votre trafic, le préjudice pour l'utilisateur et votre tolérance pour les pages fausses.
MTTR should include the entire recovery chain. If the team fixes code quickly but waits for review, propagation, or user adoption, the user-facing MTTR remains long. MTBF helps expose whether repeated emergency fixes are increasing failure frequency rather than improving the product.
Rendre le livre de procédures exécutable
Dashboards ne récupèrent pas les applications. Un livre de procédures doit mentionner le propriétaire, les critères de décision, l'action de reversion, les canaux affectés et la requête de vérification. Les ingénieurs doivent être capables d'identifier la dernière version connue et la rétablir sans reconstruire l'historique de la mise en production pendant une incidente.
Pour les équipes construisant un système de signal plus large, des conseils d'observabilité d'applications fournissent un complément utile aux vérifications de disponibilité de base. Le test opérationnel est simple : peut l'ingénieur en charge de l'appel téléphonique identifier le groupe en panne et réduire l'impact sur l'utilisateur avant la prochaine escalade de support ?
Sorties de magasin versus Mises à jour par voie aérienne
Store delivery and over-the-air delivery solve different problems. A store release is the right path for native code, operating-system integrations, entitlements, permissions, and SDK changes. It also places the fix behind review, metadata checks, signing requirements, and user installation behavior.
La mise en production de l'Apple avance automatiquement à travers 1%, 2%, 5%, 10%, 20%, 50% et 100% étapes, avec chaque étape avançant tous les 24 heurescontext . Les développeurs peuvent suspendre la progression pendant jusqu'à 30 jours cumulatifs.mais les utilisateurs qui ont déjà reçu la build la gardent, donc le rôleback signifie envoyer une version de remplacement plutôt que de retirer le code installé. Ces mécanismes sont documentés dans la ligne directrice de déploiement étape par étape.
An OTA channel can deliver JavaScript bundles, configuration, copy, and assets without waiting for a store review cycle. Teams can target cohorts by app version, geography, environment, or risk profile. That makes OTA valuable for defects above the native bridge, but it doesn’t turn native code into remotely replaceable code. A native crash caused by a binary or SDK still requires a store release.
| Dimension | Lancement de l'application | Mise à jour par le réseau |
|---|---|---|
| Meilleure correspondance | context : Page/zone : Page de produit de build natif / produit de build cloud natif. Rôle : Étiquette de navigation ou élément de navigation court. Clé de message `native_build_builder_compare_fit_feature` (Native Build Builder Compare Fit Feature). | Shell natif, permissions, SDK, intégration au système d'exploitation |
| JavaScript, CSS, configuration, contenu et ressources | Approbation | Sujet aux contrôles de revue et de politique de l'application store. |
| Action de l'utilisateur | Exige généralement l'installation ou la mise à jour d'une boutique | Peut s'appliquer à un cycle de lancement ou de mise à jour contrôlé |
| Annuler la mise à jour | context : Action de produit : annuler une mise à jour OTA. Page/zone : page de marketing de solutions Capgo. Rôle : Étiquette de navigation ou élément de menu court. Vue dans : page solutions/white-label.astro. Clé de message `solutions_white_label_visual_cell3_value` (Valeur de cellule visuelle Solutions White Label) | Exige un binaire de remplacement après distribution |
| Peut rediriger un groupe éligible vers un bundle précédent | Principal risque | Latence de revue et propagation de binaire |
A layered strategy keeps the native shell stable and moves eligible fixes through a signed OTA channel. Capgo is one example of this model, delivering encrypted, signed bundles with channel targeting for supported CapacitorJS and Electron applications. Teams evaluating the boundary between the two paths should also review Une stratégie à couches maintient la coquille native stable et fait passer les correctifs éligibles par un canal OTA signé. __CAPGO_KEEP_0__ est un exemple de ce modèle, livrant des ensembles chiffrés et signés avec ciblage de canal pour les applications Electron et CapacitorJS prises en charge. Les équipes évaluant la frontière entre les deux chemins devraient également examiner.
Mises à jour de boutique versus mises à jour directes : Rollouts, Annulations et Livraison en temps réel
La livraison sûre commence par un petit groupe, des portes de santé objectives, et une version précédente qui peut être restaurée sans débat. Une mise en vol ou une mise en phase devrait commencer avec un groupe interne et un public de production limité, puis s'agrandir uniquement lorsque les signaux de crash, les erreurs de transaction, l'installation de mise à jour et les indicateurs de support restent acceptables.
Les bundles différentiels réduisent les transferts inutiles en envoyant des actifs modifiés au lieu de reconstruire le payload entier. Les affectations de canal séparent les utilisateurs internes, les utilisateurs bêta, les anneaux de production et les flux spécifiques aux clients. Cette séparation permet à l'équipe de tester une correction contre des conditions réelles de périphérique sans exposer tous les utilisateurs à la fois.
Élargir les portes sur la base de preuves
Utilisez un enregistrement de mise à jour qui nomme le bundle, les versions natives compatibles, le propriétaire, les signaux de santé et la cible de retrait. Avant chaque expansion, vérifiez :
- Compatibilité : Le bundle fonctionne sur chaque shell natif pris en charge et ne dépend pas d'une capacité non disponible.
- Intégrité : La mise à jour est signée, vérifiée et associée au canal prévu.
- Santé : Les signaux de crash, d'erreur, de latence et d'installation restent dans les limites déclarées par l'équipe.
- Rétablissement : La version précédente est disponible et l'action de réaffectation a été testée.
- Communication : Les équipes de support et les intervenants en cas d'incident savent quel groupe a reçu la mise à jour.
La livraison de mise à jour en temps réel réduit le boucle de récupération car elle peut combiner des ensembles de bord, la réaffectation de canal et l'action de reversion. Capgo prend en charge ces modèles de livraison pour les applications CapacitorJS et Electron, y compris les ensembles signés, les mises à jour différentielles, les contrôles de canal et l'observabilité des publications. La décision de conception importante n'est pas la vitesse seule. C'est s'assurer que la mise à jour rapide ne peut pas contourner la compatibilité, la propriété d'approbation ou la protection de reversion.
Règle de publication : Ne pas optimiser la vitesse de déploiement au détriment de la connaissance exacte des utilisateurs qui ont reçu la mise à jour et de la manière de les remettre en place.
Les équipes devraient documenter si une mise à jour s'applique à la prochaine mise en route, comment les téléchargements interrompus se comportent et ce qui se passe lorsqu'un appareil est hors ligne. Plus de détails sur la réversibilité sûre apparaissent dans ces stratégies de reversion pour les mises à jour en temps réel Capacitor.
Contraintes de sécurité et de conformité sur la disponibilité
Les équipes réglementées ne peuvent pas définir la disponibilité comme « expédier la correction aussi rapidement que possible ». Elles doivent préserver la confidentialité, l'intégrité, la traçabilité et le changement contrôlé tout en restaurant le parcours utilisateur. Une équipe fintech peut avoir besoin de contrôles de paiement et de preuves de libération solides. Une équipe de santé doit protéger l'intégrité des données lorsque le réseau ou un service dépendant est indisponible. Une déploiement gouvernemental peut restreindre d'où proviennent les mises à jour et quels environnements peuvent les recevoir.
Le déséquilibre pratique est entre la vitesse de récupération et la gestion de conformité. Un CDN tiers OTA peut raccourcir la fenêtre de livraison, mais une organisation fintech peut être incapable d'en faire usage jusqu'à ce que la posture de sécurité du fournisseur, les contrôles d'accès, les enregistrements de suivi et les exigences contractuelles aient été évalués. Une application de santé peut autoriser le retrait uniquement si le bundle réversé reste signé et si l'événement est conservé dans une histoire de libération traçable.
| Le cadre | Impact sur la disponibilité | Contrainte de livraison de mise à jour |
|---|---|---|
| PCI DSS | Les flux de paiement nécessitent une résilience contrôlée et un traitement de transaction protégé | Mises à jour nécessitent des preuves, des contrôles d'accès et des vérifications d'intégrité |
| PSD2 | L'authentification de paiement solide et la continuité du service façonnent la conception de récupération | Les modifications doivent préserver l'authentification et les contrôles de paiement. |
| HIPAA | Le comportement de panne doit protéger les informations de santé et l'intégrité des données. | Les redondances et les retours en arrière nécessitent un accès contrôlé et une traçabilité. |
| FedRAMP | Les environnements approuvés et les processus de modification contrainent les chemins de déploiement. | Mise à jour des origines, des approbations et des enregistrements doit s'adapter aux contrôles d'autorisation. |
| RGPD | La gestion des incidents et la protection des données personnelles affectent les décisions de récupération. | Les équipes ont besoin de modifications suivables et d'un processus de réponse pour l'exposition de données. |
La signature Code est essentielle pour les lots de mise à jour en direct. Utilisez des canaux séparés pour les environnements, restreignez qui peut publier, vérifiez la compatibilité avant l'installation et conservez l'historique des versions. La résidence des données régionales, la conservation des journaux d'audit et l'assurance du fournisseur peuvent déterminer si un canal de livraison est acceptable même lorsque sa performance technique est forte.
Les équipes de sécurité ont également besoin de preuves de tests répétables. Un article sur pénétrométrie SOC 2 automatisée peut aider les équipes à définir comment les tests automatisés s'intègrent à la validation plus large des contrôles. Il ne remplace pas la revue architecturale, l'approbation des modifications ou les exercices d'incident.
Le compromis sonore est un chemin de circulation contrôlée rapide. Approuvez préalablement les classes d'actualisation éligibles, signez chaque artefact, enregistrez chaque affectation et réservez les modifications natives ou à haut risque pour le processus de magasin formel et de conformité.
Liste de contrôle pratique de disponibilité et questions fréquentes
Utilisez cette liste comme audit opérationnel. Chaque élément doit avoir une réponse claire « fait » ou « non fait », et non une déclaration vague selon laquelle l'équipe « soutient » la disponibilité.
- Définissez les SLA : Fait signifie que la transaction utilisateur de base et la fenêtre de mesure sont documentées.
- Cartographiez les dépendances : Fait signifie que chaque composant critique API, chaque service d'identité, chaque chemin de paiement et chaque composant de bordure a un propriétaire.
- Séparez la disponibilité de la vivacité : Done signifie que les instances malades cesseront de recevoir du trafic avant de provoquer des erreurs pour les requêtes des utilisateurs.
- Testez la faille de basculement régional : Done signifie que l'équipe a exercé le déplacement du trafic et a vérifié le comportement des données.
- Ajoutez une dégradation gracieuse : Done signifie que les fonctionnalités non essentielles peuvent être désactivées sans bloquer la tâche principale.
- Instrumentez la santé du client : Done signifie que les plantages, les échecs d'actualisation et les cohortes affectées sont visibles par version.
- Définissez des alertes basées sur les changements : Done signifie que les deltas de taux d'erreur significatifs avertissent le bon répondant.
- Créez des anneaux de déploiement : Done signifie que les audiences internes, bêta et de production ont des affectations de canal explicites.
- Signez les artefacts OTA : Signifie que le client vérifie l'intégrité et la compatibilité du bundle avant l'installation.
- Définir les déclencheurs de reversion. Signifie que l'équipe a des conditions objectives pour arrêter l'expansion ou revenir en arrière.
- Nommer l'action de récupération. Signifie que l'ingénieur en charge peut exécuter et vérifier la reversion à partir du livre de run.
- Passer en revue les contrôles de conformité. Signifie que les propriétaires de la sécurité et de la conformité revisitent les permissions de livraison à mesure que le produit change.
Questions fréquentes
context":"Page/area: Appflow comparison / migration marketing copy. Role: Section or page heading. Seen in: page ionic-appflow.astro. Message key `appflow_faq_title` (Appflow FAQ Title)", Comment les équipes doivent-elles équilibrer la latence des examens de magasin avec la rapidité des correctifs chauds?
Considérez de garder la voie de magasin pour les changements natifs et utilisez une voie de mise à jour contrôlée pour les correctifs éligibles de la couche web. N'imposez pas un travail de contournement JavaScript dans un défaut natif, et ne vous attendez pas à une soumission de magasin lorsque vous pouvez résoudre l'incident en toute sécurité avec un bundle signé et compatible. Quand les déploiements étalés sur plusieurs phases surprennent-ils les lancements canari ?
How do you calculate realistic uptime during regional outages? Mesurez le parcours utilisateur par région et pesez les résultats en fonction de l'utilisation attendue. Un average global peut cacher une panne sévère pour un public, il est donc recommandé de publier à la fois la disponibilité globale et l'expérience régionale.
What distinguishes MTTR from MTBF? MTTR mesure la vitesse de récupération après une panne. MTBF mesure l'intervalle entre les pannes. Un équipe peut améliorer l'un tandis que l'autre se dégrade, il est donc recommandé de suivre les deux en même temps que les données de mise à jour et de dépendance.
Reassess the checklist quarterly and after major changes to the user base, regulatory scope, native shell, or update channels. App availability is a moving operational contract, not a one-time architecture checkbox.
Si votre équipe CapacitorJS ou Electron a besoin d'un chemin contrôlé pour les mises à jour signées de JavaScript, CSS, de la configuration et des actifs, Capgo propose des canaux de mise à jour en direct ciblés, une livraison différentielle, une histoire de mise à jour, des journaux de mise à jour au niveau du dispositif et une protection de reversion. Visitez Capgo pour évaluer comment une stratégie de livraison en couches peut réduire les fenêtres de récupération sans contourner la gouvernance des magasins pour les changements natifs.
