Deze pagina is vertaald door de Cloud Translation API.

Versiebeheer

Magdalena Skarbińska

Demián Renzulli

Geïsoleerde webapplicaties (IWA's) bieden een zeer betrouwbare, veilige en versieonafhankelijke runtime-omgeving bovenop het webplatform. In productieomgevingen – met name binnen beheerde ondernemingen – hebben beheerders en ontwikkelaars nauwkeurige controle nodig over software-implementaties.

Om aan deze vereisten te voldoen, biedt Chrome uitgebreide mogelijkheden voor versiebeheer voor IWA's, waaronder updatekanalen , versievastlegging en versie-downgrading . Deze functies zorgen voor voorspelbare implementaties en snelle herstelmogelijkheden voor uw gebruikers.

Beschikbaarheid

Het versiebeheer is afhankelijk van of de IWA door een beheerder wordt beheerd of rechtstreeks door een gebruiker is geïnstalleerd:

Beheerde IWA's: Administratieve functies (waaronder beleidsgestuurd vastzetten en downgraden) zijn beschikbaar vanaf Chrome 133 .
Niet-beheerde (door de gebruiker geïnstalleerde) IWA's: Gebruikersgerichte functies (zoals handmatige kanaalselectie) zijn beschikbaar vanaf Chrome 150 .

Compatibiliteit van sessietypen

Alle functionaliteiten voor versiebeheer, inclusief updatekanalen en versievastlegging, zijn volledig compatibel met alle ChromeOS-sessietypen. Dit omvat:

Standaard beheerde gebruikerssessies
Beheerde gastsessies (MGS)
Speciaal ontworpen kiosk- modusomgevingen

Updatekanalen

Door gebruik te maken van updatekanalen kunnen ontwikkelaars specifieke applicatiebuilds segmenteren voor verschillende implementatie- en testdoelgroepen. Om kanalen te configureren, voegt u een optioneel veld met een array van kanalen toe aan elke versievermelding in het applicatie-updatemanifest. Deze kanaalnamen zijn niet gebonden aan vaste platformtrefwoorden (zoals canary of stable ), maar zijn willekeurige, door ontwikkelaars gedefinieerde identificaties die moeten worden opgemaakt als kleine ASCII-alfanumerieke tekenreeksen (die koppeltekens of underscores mogen bevatten, maar geen spaties). Als een versievermelding het veld 'channels' volledig weglaat, stelt Chrome de beschikbaarheid impliciet in op het 'default'-kanaal. Uiteindelijk moet de kanaalnaam die in het beheerbeleid is opgegeven, exact overeenkomen met de tekenreeks die in het manifest is gedefinieerd; eventuele typografische fouten of onjuiste configuraties zullen ertoe leiden dat er geen geschikte versie wordt gevonden, waardoor updates voor die clients effectief worden geblokkeerd.

Manifestconfiguratie

Om kanalen te configureren, voegt u een optionele array channels toe aan elke versie-vermelding in uw Web App Manifest . Houd rekening met de volgende punten:

Kanaaltoewijzing: Als een versie-item een array channels definieert, komt die versie alleen in aanmerking voor installatie op de opgegeven kanalen.
De standaard terugvaloptie: als een versie-item het veld channels volledig weglaat, gaat Chrome ervan uit dat de versie uitsluitend bij het default hoort.
Exacte tekenreeksovereenkomst: Kanaalnamen die zijn opgegeven in client-side beleidsconfiguraties moeten exact overeenkomen met de tekenreeksen die zijn gedefinieerd in het updatemanifest (hoofdlettergevoelig). Als geen enkele versie overeenkomt met de beoogde kanaalnaam, kan de app geen geschikte updates vinden.

Update manifest voorbeeld

Het volgende voorbeeld toont een updatemanifest dat meerdere releasekanalen ondersteunt:

{
  "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"
    }
  ]
}

Op basis van dit manifest zijn de volgende versies beschikbaar per beoogd kanaal:

standaard: 0.2.0 , 0.4.0 (waarbij geen expliciet kanaal is opgegeven en de standaardwaarde wordt gebruikt)
delta: 0.1.0 , 0.2.0 , 0.3.0
bèta: 0.3.0

De IWA-update-engine ondersteunt het targeten van specifieke releasekanalen door te zoeken naar een veld 'channels' in het updatemanifest van de app.

Versie vastzetten

In bedrijfsomgevingen met hoge compliance-eisen of een hoge stabiliteit moeten beheerders ervoor zorgen dat apparaten exact dezelfde versies van bedrijfskritieke software draaien. Met versiebeheer kunnen beheerders een IWA (Integrated Workspace Area) vergrendelen op een specifieke versie, waardoor alle volgende updates op de achtergrond worden gestopt. Dit biedt bedrijven een zeer betrouwbare manier om stabiele configuraties te behouden en te voldoen aan strenge interne of branchevoorschriften.

Om een Isolated Web App (IWA) te bevriezen op een specifieke releaseversie, kunnen bedrijfsbeheerders de eigenschap pinned_version configureren in het beleid ` IsolatedWebAppInstallForceList` . Deze functionaliteit wordt voornamelijk beheerd via de interactieve UI-elementen in de Google Admin Console onder het detailvenster van de applicatie, volgens de standaard IWA-installatieworkflow . Beheerders behouden echter ook de flexibiliteit om deze beleidswaarden rechtstreeks te implementeren met behulp van ruwe JSON-configuraties. Zodra een geldige versiestring succesvol is geselecteerd door de beheerder, haalt Chrome dat specifieke pakket op en blokkeert alle daaropvolgende automatische updates.

Bijzondere gedragingen en beperkingen

Updates hervatten (loskoppelen): Om automatische updates te herstellen, verwijdert u de eigenschap pinned_version of wijzigt u de waarde ervan in een nieuwere doelversie.
Standaard geen downgrade: Als u pinned_version instelt op een versie lager dan de momenteel geïnstalleerde versie, wordt er geen terugdraaiing uitgevoerd, tenzij allow_downgrades expliciet is ingeschakeld.
Niet-beschikbare pin-doelen: Als de geconfigureerde pinned_version ontbreekt in het aangewezen updatekanaal, of ouder is dan de geïnstalleerde versie (met uitgeschakelde downgrades), behoudt Chrome de momenteel geïnstalleerde versie en blokkeert verdere updates.
Nieuwe implementaties: Als een IWA nog niet is geïnstalleerd op een beheerd apparaat en de opgegeven pinned_version niet kan worden opgehaald of ontbreekt in het updatemanifest, zal de IWA-installatie mislukken.

versie downgraden

Als een recent uitgebrachte update een kritieke bug of kwetsbaarheid introduceert, moeten beheerders apparaten mogelijk terugzetten naar een eerdere stabiele versie. Chrome ondersteunt het downgraden van reeds geïnstalleerde beheerde IWA's naar een lagere versie – een mogelijkheid die voorheen niet beschikbaar was op het platform toen alleen voorwaartse updates waren toegestaan.

Een verlaging van de kredietwaardigheid is alleen mogelijk als aan beide volgende beleidsvoorwaarden is voldaan:

pinned_version is ingesteld op een geldige, oudere versie.
allow_downgrades is expliciet ingesteld op true.

Hoe downgrades werken

Activeringsmechanisme: Terugdraaien wordt verwerkt tijdens de reguliere updatecontrolecyclus (die elke 4-6 uur plaatsvindt).
Achter de schermen: Chrome voert een volledige herinstallatie van de IWA uit met behulp van de oudere webbundel (.swbn) die in het updatemanifest is gespecificeerd.

Logica voor kanaalovergang

Bij het wijzigen van het beoogde kanaal van een app met behulp van een beleid, houdt de update-engine zich aan specifieke gedragingen:

Scenario A: Overschakelen naar een kanaal met eerdere versies

Als downgraden is toegestaan: Als pinned_version overeenkomt met een oudere versie op het doelkanaal en allow_downgrades waar is, vindt er een rollback plaats (en worden lokale gebruikersgegevens gewist).
Als downgraden niet is toegestaan: Er vindt geen downgrade plaats. Het apparaat blijft op de momenteel geïnstalleerde, hogere versie en wordt alleen bijgewerkt wanneer een nieuwere versie beschikbaar komt op het nieuw geselecteerde kanaal.

Scenario B: Overschakelen naar een kanaal met een identieke versie

Geen wijzigingen: Als het nieuw geselecteerde kanaal verwijst naar een versienummer dat gelijk is aan het momenteel geïnstalleerde versienummer, zal Chrome geen wijzigingen aanbrengen in het geïnstalleerde pakket.
Principe van byte-voor-byte-identiteit: ontwikkelaars moeten garanderen dat identieke versienummers op verschillende kanalen identieke, byte-overeenkomende codehandtekeningen bevatten. Het implementeren van verschillende codebases onder dezelfde versieaanduiding op verschillende kanalen kan leiden tot onverwachte, onvoorspelbare applicatietoestanden.

Configuratie van administratief beleid

Versiebeheer voor bedrijven wordt afgedwongen via het gecentraliseerde Google Admin Console-platform met behulp van het beleidsschema IsolatedWebAppInstallForceList . Deze instellingen kunnen rechtstreeks worden beheerd via UI-elementen in de Admin Console of worden geïmplementeerd met behulp van ruwe JSON-beleidsconfiguraties.
Het volgende voorbeeld van de configuratie van een beheerdersbeleid demonstreert updatekanalen, versiebeheer en downgrades:

Vertegenwoordiging van beleidswaarden

[
  {
    "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
  }
]

Uitleg van schema-parameters

channel (string, optioneel) : Geeft Chrome de instructie om alleen versies te evalueren die aan dit kanaal zijn toegewezen in het updatemanifest. Indien weggelaten, evalueert Chrome het "standaard" kanaal.
pinned_version (string, optioneel) : Hiermee wordt het apparaat expliciet vergrendeld op de opgegeven versie. Latere automatische achtergrondupdates worden geblokkeerd.
allow_downgrades (boolean, optioneel) : Schakelt de mogelijkheid tot terugdraaien in. Indien waar en in combinatie met een geldige, oudere pinned_version , zal Chrome een downgrade-installatie uitvoeren. Waarschuwing: Als deze parameter op waar wordt ingesteld, worden alle standaard voorwaartse updates geblokkeerd, zelfs als het veld pinned_version ontbreekt.

Niet-beheerde (door de gebruiker geïnstalleerde) IWA's (vanaf 150)

Voor onbeheerde, door de gebruiker geïnstalleerde geïsoleerde webapplicaties werkt versiebeheer met handmatige gebruikersinteracties:

Installatiepakket ──► Gebruiker selecteert kanaal ──► Automatische controle van geselecteerd kanaal

Manifestvereiste voor automatische updates

Om ervoor te zorgen dat door de gebruiker geïnstalleerde IWA's automatisch periodieke updates op de achtergrond kunnen controleren en ontvangen, moet het lokale Web App Manifest van de app (de metadata in het bundelbestand op /.well-known/manifest.webmanifest ) een geldig update_manifest_url veld bevatten.

Als deze URL ontbreekt in het lokale manifestbestand van de applicatie, zal de onbeheerde update-engine nooit achtergrondcontroles uitvoeren en blijft de applicatie permanent vastzitten op de oorspronkelijke installatieversie.

Handmatige kanaalselectie

Tijdens de eerste installatie van een onbeheerde IWA controleert de browser het updatemanifest en toont de beschikbare kanaalopties (bijvoorbeeld "Stable", "Beta") direct aan de gebruiker als de ontwikkelaar meerdere kanalen heeft geconfigureerd.

Belangrijke levenscyclusregels

Installatielocatie bij de eerste installatie: Ongeacht het kanaal dat de gebruiker tijdens de installatie selecteert, worden bij de eerste installatie altijd de bestanden uit het meegeleverde installatiepakket geïnstalleerd.
Latere updates: Na installatie worden toekomstige updates uitsluitend via het gekozen kanaal opgevraagd. De app wordt alleen bijgewerkt wanneer een versie die nieuwer is dan de geïnstalleerde versie, via dat kanaal wordt gepubliceerd.
Van kanaal wisselen: Om na de installatie over te schakelen naar een ander updatekanaal, moet de gebruiker IWA verwijderen en opnieuw installeren, waarbij het gewenste kanaal tijdens de installatieprocedure wordt geselecteerd.

Hoe test je beheerde implementaties?

Voor beheerders die apparaten beheren via de Chrome Enterprise Admin Console of rechtstreeks beleid configureren:

Ga naar het paneel 'App-details' onder de organisatie-instellingen.
Pas configuratie-eigenschappen toe om pinning- en kanaaldoelen te testen. Omdat deze besturingselementen volledig compatibel zijn met standaard gebruikerssessies, beheerde gastsessies (MGS) en kiosken, kunt u het gedrag in alle implementatieomgevingen controleren.
Om de updatecontroles lokaal te inspecteren, ga je op een testclient naar chrome://web-app-internals om handmatig updatecontroles af te dwingen en de binnenkomende manifestpakketten te analyseren.

Conclusie

De beveiligingsarchitectuur van Isolated Web Apps is ontworpen om ontwikkelaars meer mogelijkheden te bieden, terwijl tegelijkertijd strikte voorspelbaarheid en controle over het gedrag van de applicatielevenscyclus worden gewaarborgd. Door gebruik te maken van de versiebeheerfuncties van Chrome kunnen zowel ontwikkelaars als IT-beheerders robuuste implementatiepipelines bouwen die voldoen aan strenge compliance-normen en operationele doelstellingen.

Houd bij het ontwerpen en beheren van de update-strategie voor uw applicatie de volgende kernprincipes in gedachten:

Gebruik progressieve kanalen: Updatekanalen (zoals beta , dev of aangepaste kanalen) stellen je in staat om stapsgewijs telemetrie en feedback te verzamelen. Dit zorgt ervoor dat belangrijke updates een strenge verificatie ondergaan voordat ze beschikbaar komen voor het grote publiek op het standaardkanaal.
Vergrendelen voor stabiliteit: In sterk gestructureerde of op compliance gerichte bedrijfsomgevingen kunt u kritieke eindpunten vergrendelen aan een geverifieerde, exacte vastgezette versie om de bedrijfsvoering te beschermen tegen onverwachte storingen of onderbrekingen van de workflow.
Gebruik downgrades alleen in noodgevallen: besef dat downgraden naar een eerdere versie een krachtig, corrigerend veiligheidsmechanisme is dat voorheen onmogelijk was. Omdat een rollback echter een volledige herinstallatie activeert en alle lokale clientopslag (IndexedDB, LocalStorage, cookies) wist, moet deze strikt worden voorbehouden aan kritieke beveiligingsmaatregelen. Voor reguliere patches is het uitrollen van een kleine, toekomstgerichte update altijd de ideale strategie.
Begrijp de beleidsvlaggen: Wees alert op beheerdersopties; het inschakelen van allow_downgrades zal alle voorwaartse updates stoppen, zelfs als er geen pincode actief is gedefinieerd.
Zorg voor byte-voor-byte-integriteit: garandeer dat identieke versienummers die via verschillende kanalen worden ingezet, overeenkomen met identieke, byte-overeenkomende bundels om onregelmatige applicatiestatussen te voorkomen wanneer clients tussen kanalen overschakelen.

Door deze functies rechtstreeks in uw updatemanifest en bedrijfsbeleidsschema te integreren, kunt u een betrouwbare, controleerbare en veilige updateflow garanderen die de hoge vertrouwensgaranties van het Isolated Web App-ecosysteem waarborgt.