Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Gestion des versions

Magdalena Skarbińska

Demián Renzulli

Les applications Web isolées (AWI) offrent un environnement d’exécution hautement fiable, sécurisé, et discret en termes de version sur la plate-forme Web. Dans les environnements de production, en particulier au sein des entreprises gérées, les administrateurs et les développeurs ont besoin d'un contrôle précis sur les déploiements de logiciels.

Pour répondre à ces exigences, Chrome fournit des fonctionnalités complètes de gestion des versions pour les AWI, y compris les canaux de mise à jour, l'épinglage de version et le retour à une version antérieure. Ces fonctionnalités permettent de prévoir le déploiement et de contrôler la récupération rapide sur l'ensemble de votre base d'utilisateurs.

Disponibilité

Le comportement de la gestion des versions dépend de si l'AWI est gérée par un administrateur ou installée directement par un utilisateur :

AWI gérées : les fonctionnalités d'administration (y compris l'épinglage et le retour à une version antérieure basés sur des règles) sont disponibles à partir de Chrome 133.
AWI non gérées (installées par l'utilisateur) : les fonctionnalités destinées aux utilisateurs (telles que la sélection manuelle des canaux) sont disponibles à partir de Chrome 150.

Compatibilité des types de sessions

Toutes les fonctionnalités de gestion des versions, y compris les canaux de mise à jour et l'épinglage de version, sont entièrement compatibles avec tous les types de sessions ChromeOS. Par exemple :

Sessions utilisateur gérées standards
Sessions Invité gérées (MGS)
Environnements dédiés en mode Kiosque

Mettre à jour les canaux

En utilisant des canaux de mise à jour, les développeurs peuvent segmenter des compilations d'applications spécifiques pour différents types de déploiement et d'audiences de test. Pour configurer des canaux, ajoutez un champ de tableau de canaux facultatif à chaque entrée de version dans le fichier manifeste de mise à jour de l'application. Ces noms de canaux ne sont pas limités à des mots clés de plate-forme fixes (comme canary ou stable), mais sont plutôt des identifiants arbitraires définis par le développeur qui doivent être mis en forme sous forme de chaînes alphanumériques ASCII en minuscules (qui peuvent inclure des traits d'union ou des traits de soulignement, mais pas d'espaces). Si une entrée de version omet complètement le champ des canaux, Chrome définit implicitement sa disponibilité sur le canal "default". En fin de compte, le nom de la chaîne désigné dans la règle d'administration doit correspondre exactement à la chaîne définie dans le fichier manifeste. Toute erreur typographique ou toute configuration non concordante empêchera l'identification d'une version éligible, ce qui interrompra les mises à jour pour ces clients.

Configuration du fichier manifeste

Pour configurer des canaux, ajoutez un tableau channels facultatif à chaque entrée de version dans votre fichier manifeste de l'application Web. Voici quelques points à prendre en compte :

Mappage des canaux : si une entrée de version définit un tableau channels, cette version n'est éligible à l'installation que sur les canaux spécifiés.
Remplacement par défaut : si une entrée de version omet complètement le champ channels, Chrome suppose que la version appartient exclusivement au canal default.
Correspondance exacte des chaînes : les noms de canaux spécifiés dans les configurations de règles côté client doivent correspondre exactement aux chaînes définies dans le fichier manifeste de mise à jour (sensibles à la casse). Si aucune version ne correspond au nom de la chaîne ciblé, l'application ne trouvera pas de mises à jour éligibles.

Exemple de fichier manifeste de mise à jour

L'exemple suivant montre un fichier manifeste de mise à jour compatible avec plusieurs canaux de publication :

{
  "versions": [
    {
      "version": "0.1.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.1.0/iwa-sink.swbn",
      "channels": ["delta"]
    },
    {
      "version": "0.2.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.2.0/iwa-sink.swbn",
      "channels": ["delta", "default"]
    },
    {
      "version": "0.3.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.3.0/iwa-sink.swbn",
      "channels": ["beta", "delta"]
    },
    {
      "version": "0.4.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.4.0/iwa-sink.swbn"
    }
  ]
}

D'après ce fichier manifeste, les versions suivantes sont disponibles par canal ciblé :

default : 0.2.0,0.4.0 (qui ne comporte pas de canal explicite et est défini par défaut sur "default")
delta : 0.1.0, 0.2.0, 0.3.0
beta : 0.3.0

Le moteur de mise à jour des AWI est compatible avec le ciblage de canaux de publication spécifiques en recherchant un champ de canaux dans le fichier manifeste de mise à jour de l'application.

Épinglage

Dans les environnements d'entreprise hautement conformes ou très stables, les administrateurs doivent s'assurer que les appareils exécutent des versions exactes de logiciels essentiels. L'épinglage de version permet aux administrateurs de verrouiller une AWI sur une version spécifique, ce qui interrompt toutes les mises à jour en arrière-plan ultérieures. Cela permet aux entreprises de maintenir des configurations stables de manière très fiable et de se conformer à des réglementations internes ou sectorielles strictes.

Pour bloquer une application Web isolée (AWI) sur une version spécifique, les administrateurs d'entreprise peuvent configurer la propriété pinned_version dans la IsolatedWebAppInstallForceList. Cette fonctionnalité est principalement gérée via les commandes interactives de l'interface utilisateur dans la console d'administration Google, dans le panneau des détails de l'application, en suivant le workflow d'installation standard des AWI. Toutefois, les administrateurs peuvent également déployer ces valeurs de règles directement à l'aide de configurations JSON brutes. Une fois qu'une chaîne de version valide est correctement ciblée par l'administrateur, Chrome extrait ce package explicite et bloque toutes les mises à jour automatiques ultérieures.

Comportements et contraintes spécifiques

Reprise des mises à jour (désépinglage) : pour restaurer les mises à jour automatiques, supprimez la propriété pinned_version ou remplacez sa valeur par une version cible plus récente.
Aucun retour à une version antérieure par défaut : si vous définissez pinned_version sur une version antérieure à celle actuellement installée, aucun rollback ne sera déclenché, sauf si allow_downgrades est explicitement activé.
Cibles d'épinglage non disponibles : si la pinned_version configurée est manquante dans le canal de mise à jour désigné ou est antérieure à la version installée (avec les retours à une version antérieure désactivés), Chrome conserve la version actuellement installée et bloque toute mise à jour ultérieure.
Déploiements récents : si une AWI n'est pas encore installée sur un appareil géré et que la pinned_version spécifiée ne peut pas être récupérée ou est manquante dans le fichier manifeste de mise à jour, l'AWI ne pourra pas être installée.

Retour à une version antérieure

Si une mise à jour récemment déployée introduit un bug ou une faille critique, les administrateurs peuvent avoir besoin d'effectuer un rollback sur les appareils vers un état stable antérieur. Chrome est compatible avec le retour à une version antérieure des AWI gérées déjà installées. Cette fonctionnalité n'était auparavant pas disponible sur la plate-forme lorsque seules les mises à jour étaient autorisées.

Le retour à une version antérieure n'est possible que si les deux conditions de règles suivantes sont remplies :

pinned_version est défini sur une version antérieure valide.
allow_downgrades est explicitement défini sur "true".

Fonctionnement des retours à une version antérieure

Mécanisme de déclenchement : les rollbacks sont traités lors du cycle de vérification des mises à jour régulier (qui s'exécute toutes les 4 à 6 heures).
En coulisses : Chrome effectue une réinstallation complète de l'AWI à l'aide de l'ancien bundle Web (.swbn) spécifié dans le fichier manifeste de mise à jour.

Logique de transition des canaux

Lorsque vous changez le canal ciblé d'une application avec une règle, le moteur de mise à jour respecte des comportements spécifiques :

Scénario A : Passer à un canal avec des versions antérieures

Si le retour à une version antérieure est autorisé : si pinned_version correspond à une version antérieure sur le canal cible et que allow_downgrades est défini sur "true", un rollback se produit (et les données utilisateur locales sont effacées).
Si le retour à une version antérieure n'est pas autorisé : aucun rollback ne se produit. L'appareil conserve la version supérieure actuellement installée et ne sera mis à jour que lorsqu'une version plus récente sera disponible sur le canal nouvellement sélectionné.

Scénario B : Passer à un canal avec une version identique

Aucune modification : si le canal nouvellement sélectionné pointe vers un numéro de version égal à celui actuellement installé, Chrome n'apporte aucune modification au bundle installé.
Principe d'identité octet par octet : les développeurs doivent garantir que les numéros de version identiques sur différents canaux contiennent des signatures de code identiques et correspondantes octet par octet. Le déploiement de différents codebases sous la même chaîne de version sur différents canaux peut entraîner des états d'application inattendus et erratiques.

Configuration des règles d'administration

Les contrôles de version d'entreprise sont appliqués avec la plate-forme centralisée de la console d'administration Google à l'aide du IsolatedWebAppInstallForceList. Ces paramètres peuvent être gérés directement via les commandes de l'interface utilisateur de la console d'administration ou déployés à l'aide de configurations de règles JSON brutes.
L'exemple de configuration de règles d'administration suivant illustre les canaux de mise à jour, l'épinglage de version et les retours à une version antérieure :

Représentation de la valeur de la règle

[
  {
    "update_manifest_url": "https://awesome-kitchen-sink.glitch.me/update.json",
    "web_bundle_id": "aiv4bxauvcu3zvbu6r5yynoh4atkzqqaoeof5mwz54b4zfywcrjuoaacai",
    "channel": "beta",
    "pinned_version": "0.7.0",
    "allow_downgrades": true
  }
]

Explications des paramètres du schéma

channel (chaîne, facultatif) : indique à Chrome de n'évaluer que les versions attribuées à ce canal dans le fichier manifeste de mise à jour. Si cette valeur est omise, Chrome évalue le canal "default".
pinned_version (chaîne, facultatif): verrouille explicitement l'appareil sur la chaîne de version spécifiée. Les mises à jour automatiques en arrière-plan ultérieures sont bloquées.
allow_downgrades (booléen, facultatif) : active la fonctionnalité de rollback. Si la valeur est "true" et qu'elle est associée à une pinned_version antérieure valide, Chrome déclenche une réinstallation de retour à une version antérieure. Avertissement : si vous définissez ce paramètre sur "true", toutes les mises à jour standards seront bloquées, même si le champ pinned_version est omis.

AWI non gérées (installées par l'utilisateur) (à partir de la version 150)

Pour les applications Web isolées non gérées et installées par l'utilisateur, la gestion des versions fonctionne avec des interactions manuelles de l'utilisateur :

Bundle d'installation ──► L'utilisateur sélectionne le canal ──► Vérifications automatiques sur le canal sélectionné

Prérequis du fichier manifeste pour les mises à jour automatiques

Pour que les AWI installées par l'utilisateur puissent rechercher et recevoir des mises à jour automatiques périodiques en arrière-plan, le fichier manifeste de l'application Web local (les métadonnées empaquetées dans le bundle à l'adresse /.well-known/manifest.webmanifest) doit contenir un champ update_manifest_url valide.

Si cette URL est omise dans le fichier manifeste local de l'application, le moteur de mise à jour non géré n'effectuera jamais de vérifications en arrière-plan, et l'application restera bloquée de manière permanente sur sa version d'installation initiale.

Sélection manuelle du canal

Lors de l'installation initiale d'une AWI non gérée, le navigateur vérifie le fichier manifeste de mise à jour et affiche directement les options de canaux disponibles à l'utilisateur (par exemple, "Stable", "Beta") si le développeur a configuré plusieurs canaux.

Règles clés du cycle de vie

Origine de la première installation : quel que soit le canal sélectionné par l'utilisateur lors de l'installation, l'installation initiale déploie toujours les fichiers empaquetés dans le bundle d'installation fourni.
Mises à jour ultérieures : une fois l'application installée, les mises à jour futures ne sont interrogées qu'à partir du canal choisi. L'application ne sera mise à jour que lorsqu'une version supérieure à celle installée sera publiée sur ce canal ciblé.
Changement de canal : pour passer à un autre canal de mise à jour après l'installation, l'utilisateur doit désinstaller l'AWI et la réinstaller, en choisissant le canal sélectionné lors du processus d'installation.

Tester les déploiements gérés

Pour les administrateurs qui gèrent des appareils via la console d'administration Chrome Enterprise ou qui configurent directement des règles :

Accédez au panneau Détails de l'application dans les paramètres de l'organisation.
Appliquez des propriétés de configuration pour tester l'épinglage et les cibles de canaux. Comme ces commandes sont entièrement compatibles avec les sessions utilisateur standards, les sessions Invité gérées (MGS) et les kiosques, vous pouvez vérifier les comportements dans tous les environnements de déploiement cibles.
Pour inspecter les vérifications de mise à jour localement, accédez à chrome://web-app-internals sur un client de test afin de forcer manuellement les vérifications de mise à jour et d'analyser les paquets de fichiers manifestes entrants.

Conclusion

L'architecture de sécurité des applications Web isolées est conçue pour donner aux développeurs les moyens d'agir tout en maintenant une prévisibilité et un contrôle stricts sur les comportements du cycle de vie des applications. En tirant parti des fonctionnalités de gestion des versions de Chrome, les développeurs et les administrateurs informatiques peuvent créer des pipelines de déploiement robustes qui s'alignent sur des normes de conformité strictes et des objectifs opérationnels.

Lorsque vous concevez et gérez la stratégie de mise à jour de votre application, gardez à l'esprit ces principes fondamentaux :

Utilisez des canaux progressifs : les canaux de mise à jour (tels que beta, dev ou les anneaux personnalisés) vous permettent de collecter progressivement des données de télémétrie et des commentaires. Cela garantit que les mises à jour majeures font l'objet d'une vérification rigoureuse avant d'être mises à disposition du grand public sur le canal par défaut.
Épinglez pour plus de stabilité : dans les environnements d'entreprise hautement structurés ou axés sur la conformité, verrouillez les points de terminaison critiques sur une pinned_version exacte et vérifiée pour protéger les opérations contre les pannes inattendues ou les interruptions de workflow.
Réservez les retours à une version antérieure aux urgences : reconnaissez que le retour à une version antérieure est une soupape de sécurité corrective puissante qui était auparavant impossible. Toutefois, comme un rollback déclenche une réinstallation complète et efface tout le stockage client local (IndexedDB, LocalStorage, cookies), il doit être strictement réservé aux corrections de sécurité critiques. Pour les correctifs ordinaires, le déploiement d'une mise à jour mineure est toujours la stratégie idéale.
Comprenez les indicateurs de règles : tenez compte des commutateurs d'administration. L'activation de allow_downgrades interrompt toutes les mises à jour, même si aucune épingle n'est définie activement.
Établissez une intégrité octet par octet : assurez-vous que les numéros de version identiques déployés sur différents canaux correspondent à des bundles identiques et correspondants octet par octet pour éviter les états d'application erratiques lorsque les clients passent d'un canal à un autre.

En intégrant ces fonctionnalités directement dans votre fichier manifeste de mise à jour et votre schéma de règles d'entreprise, vous pouvez garantir un flux de mise à jour fiable, auditable et sécurisé qui préserve les garanties de haute confiance de l'écosystème des applications Web isolées.