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

Zarządzanie wersjami

Magdalena Skarbińska

Demián Renzulli

Izolowane aplikacje internetowe (IWA) oferują bezpieczne środowisko wykonawcze o wysokim poziomie zaufania, które jest odizolowane i ma określoną wersję. W środowiskach produkcyjnych – zwłaszcza w zarządzanych firmach – administratorzy i deweloperzy potrzebują precyzyjnej kontroli nad wdrażaniem oprogramowania.

Aby spełnić te wymagania, Chrome udostępnia kompleksowe funkcje zarządzania wersjami IWA, w tym kanały aktualizacji, przypinanie wersji i obniżanie wersji. Funkcje te zapewniają przewidywalność wdrażania i szybkie przywracanie kontroli w przypadku wszystkich użytkowników.

Dostępność

Działanie zarządzania wersjami zależy od tego, czy aplikacja internetowa jest zarządzana przez administratora, czy została zainstalowana bezpośrednio przez użytkownika:

Zarządzane izolowane aplikacje internetowe: funkcje administracyjne (w tym przypinanie i obniżanie wersji oparte na zasadach) są dostępne od Chrome 133.
Niezarządzane (zainstalowane przez użytkownika) IWAs: funkcje dostępne dla użytkowników (np. ręczny wybór kanału) są dostępne od Chrome 150.

Zgodność typów sesji

Wszystkie funkcje zarządzania wersjami, w tym kanały aktualizacji i przypinanie wersji, są w pełni kompatybilne ze wszystkimi typami sesji ChromeOS. Obejmuje to m.in.:

Standardowe zarządzane sesje użytkowników
Zarządzane sesje gościa
Środowiska w trybie kiosku

Aktualizowanie kanałów

Dzięki kanałom aktualizacji deweloperzy mogą dzielić poszczególne kompilacje aplikacji na segmenty dla różnych odbiorców, do których będą wdrażane i testowane. Aby skonfigurować kanały, dodaj opcjonalne pole tablicy kanałów do każdego wpisu wersji w pliku manifestu aktualizacji aplikacji. Nazwy kanałów nie są ograniczone do stałych słów kluczowych platformy (takich jak canary lub stable), ale są dowolnymi identyfikatorami zdefiniowanymi przez dewelopera, które muszą być sformatowane jako ciągi alfanumeryczne ASCII pisane małymi literami (mogą zawierać łączniki lub znaki podkreślenia, ale nie mogą zawierać spacji). Jeśli wpis wersji całkowicie pomija pole kanałów, Chrome domyślnie ustawia dostępność na kanał „default”. Nazwa kanału określona w zasadach administracyjnych musi dokładnie odpowiadać ciągowi znaków zdefiniowanemu w pliku manifestu. Wszelkie błędy typograficzne lub niezgodne konfiguracje spowodują, że nie zostanie zidentyfikowana żadna kwalifikująca się wersja, co w praktyce wstrzyma aktualizacje na tych klientach.

Konfiguracja pliku manifestu

Aby skonfigurować kanały, dodaj opcjonalną tablicę channels do każdego wpisu wersji w pliku manifestu aplikacji internetowej. Oto kilka kwestii, które warto wziąć pod uwagę:

Mapowanie kanałów: jeśli wpis wersji definiuje tablicę channels, ta wersja może być zainstalowana tylko na określonych kanałach.
Domyślne zachowanie: jeśli wpis wersji całkowicie pomija pole channels, Chrome zakłada, że wersja należy wyłącznie do kanału default.
Dokładne dopasowanie ciągu znaków: nazwy kanałów określone w konfiguracjach zasad po stronie klienta muszą dokładnie odpowiadać ciągom znaków zdefiniowanym w manifeście aktualizacji (z uwzględnieniem wielkości liter). Jeśli żadna wersja nie pasuje do nazwy kanału docelowego, aplikacja nie znajdzie odpowiednich aktualizacji.

Przykład aktualizacji pliku manifestu

Poniższy przykład pokazuje plik manifestu aktualizacji obsługujący wiele kanałów wersji:

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

Na podstawie tego pliku manifestu w przypadku każdego kanału docelowego dostępne są te wersje:

domyślny: 0.2.0,0.4.0 (który nie ma wyraźnie określonego kanału i domyślnie przyjmuje wartość domyślną)
delta: 0.1.0, 0.2.0, 0.3.0
beta: 0.3.0

Silnik aktualizacji aplikacji IWA obsługuje kierowanie na określone kanały wersji, wyszukując pole channels w pliku manifestu aktualizacji aplikacji.

Przypinanie wersji

W środowiskach korporacyjnych o wysokich wymaganiach dotyczących zgodności lub stabilności administratorzy muszą dbać o to, aby na urządzeniach działały dokładne wersje oprogramowania o znaczeniu krytycznym dla firmy. Przypinanie wersji umożliwia administratorom zablokowanie aplikacji IWA w określonej wersji, co zatrzymuje wszystkie kolejne aktualizacje w tle. Zapewnia to firmom wysoce niezawodny sposób na utrzymanie stabilnych konfiguracji i zachowanie zgodności z rygorystycznymi przepisami wewnętrznymi lub branżowymi.

Aby zamrozić izolowaną aplikację internetową (IWA) w określonej wersji, administratorzy firmowi mogą skonfigurować właściwość pinned_version w zasadzie IsolatedWebAppInstallForceList. Tą funkcją zarządza się głównie za pomocą interaktywnych elementów interfejsu w konsoli administracyjnej Google w panelu szczegółów aplikacji zgodnie ze standardowym procesem instalacji IWA. Administratorzy mogą jednak również wdrażać te wartości zasad bezpośrednio za pomocą konfiguracji w formacie JSON. Gdy administrator wybierze prawidłowy ciąg wersji, Chrome pobierze ten konkretny pakiet i zablokuje wszystkie kolejne automatyczne aktualizacje.

Specjalne zachowania i ograniczenia

Wznawianie aktualizacji (odpinanie): aby przywrócić automatyczne aktualizacje, usuń właściwość pinned_version lub zmień jej wartość na nowszą wersję docelową.
Brak starszej wersji domyślnie: ustawienie pinned_version na wersję starszą niż aktualnie zainstalowana nie spowoduje przywrócenia starszej wersji, chyba że zasada allow_downgrades zostanie wyraźnie włączona.
Niedostępne wersje docelowe: jeśli skonfigurowana pinned_version jest niedostępna w wyznaczonym kanale aktualizacji lub jest starsza niż zainstalowana wersja (przy wyłączonym obniżaniu wersji), Chrome zachowa obecnie zainstalowaną wersję i zablokuje dalsze aktualizacje.
Nowe wdrożenia: jeśli aplikacja IWA nie jest jeszcze zainstalowana na zarządzanym urządzeniu, a określonej wersji pinned_version nie można pobrać lub brakuje jej w pliku manifestu aktualizacji, instalacja aplikacji IWA nie powiedzie się.

Zmiana na starszą wersję

Jeśli nowo wdrożona aktualizacja wprowadza krytyczny błąd lub lukę w zabezpieczeniach, administratorzy mogą wycofać zmiany na urządzeniach do poprzedniego stabilnego stanu. Chrome umożliwia przywrócenie już zainstalowanych zarządzanych izolowanych aplikacji internetowych do starszej wersji. Ta funkcja była wcześniej niedostępna na platformie, na której dozwolone były tylko aktualizacje do nowszych wersji.

Obniżenie wersji jest możliwe tylko wtedy, gdy oba z tych warunków są spełnione:

pinned_version jest ustawiona na prawidłową, starszą wersję.
allow_downgrades ma wyraźnie ustawioną wartość „true”.

Jak działa przejście na niższą wersję

Mechanizm wyzwalający: wycofania są przetwarzane podczas regularnego cyklu sprawdzania aktualizacji (który jest uruchamiany co 4–6 godzin).
Pod maską: Chrome przeprowadza pełną ponowną instalację aplikacji IWA przy użyciu starszego pakietu internetowego (.swbn) określonego w pliku manifestu aktualizacji.

Logika przejścia kanału

Podczas przełączania kanału docelowego aplikacji za pomocą zasady silnik aktualizacji zachowuje się w określony sposób:

Scenariusz A: przełączanie się na kanał ze starszymi wersjami

Jeśli przywrócenie starszej wersji jest dozwolone: jeśli pinned_version pasuje do starszej wersji w kanale docelowym, a wartość allow_downgrades to „true”, następuje wycofanie (a lokalne dane użytkownika są usuwane).
Jeśli obniżenie wersji jest niedozwolone: obniżenie wersji nie nastąpi. Urządzenie pozostanie w obecnie zainstalowanej nowszej wersji i zostanie zaktualizowane dopiero wtedy, gdy w nowo wybranym kanale pojawi się nowsza wersja.

Scenariusz B: przełączanie się na kanał z identyczną wersją

Brak zmian: jeśli nowo wybrany kanał wskazuje numer wersji równy obecnie zainstalowanej, Chrome nie wprowadzi żadnych zmian w zainstalowanym pakiecie.
Zasada identyczności bajt po bajcie: deweloperzy muszą zagwarantować, że identyczne numery wersji w różnych kanałach zawierają identyczne sygnatury kodu, które są zgodne bajt po bajcie. Wdrażanie różnych baz kodu pod tym samym ciągiem wersji w różnych kanałach może powodować nieoczekiwane, niestabilne stany aplikacji.

Konfiguracja zasad administracyjnych

Wersje firmowe są kontrolowane za pomocą scentralizowanej platformy konsoli administracyjnej Google przy użyciu schematu zasady IsolatedWebAppInstallForceList. Tymi ustawieniami można zarządzać bezpośrednio za pomocą elementów interfejsu w konsoli administracyjnej lub wdrażać je za pomocą konfiguracji zasad w formacie JSON.
Poniższy przykład konfiguracji zasad administracyjnych pokazuje kanały aktualizacji, przypinanie wersji i obniżanie wersji:

Reprezentacja wartości zasady

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

Wyjaśnienia parametrów schematu

channel (ciąg znaków, opcjonalny): nakazuje Chrome oceniać w pliku manifestu aktualizacji tylko wersje przypisane do tego kanału. Jeśli zostanie pominięty, Chrome oceni kanał „default”.
pinned_version (ciąg znaków, opcjonalny): wyraźnie blokuje urządzenie w określonej wersji. Kolejne automatyczne aktualizacje w tle są blokowane.
allow_downgrades (wartość logiczna, opcjonalnie): włącza możliwość wycofania zmian. Jeśli ma wartość Prawda i jest połączona z prawidłową, starszą wersją pinned_version, Chrome wywoła ponowną instalację starszej wersji. Ostrzeżenie: ustawienie tego parametru na „true” (prawda) zablokuje wszystkie standardowe aktualizacje, nawet jeśli pole pinned_version zostanie pominięte.

Niezarządzane (instalowane przez użytkowników) aplikacje IWA (od 150)

W przypadku niezarządzanych, zainstalowanych przez użytkownika izolowanych aplikacji internetowych obsługa wersji odbywa się w ramach ręcznych interakcji użytkownika:

Pakiet instalacyjny ──► Użytkownik wybiera kanał ──► Automatyczne sprawdzanie wybranego kanału

Wymagania dotyczące pliku manifestu w przypadku automatycznych aktualizacji

Aby zainstalowane przez użytkownika aplikacje internetowe mogły sprawdzać dostępność automatycznych okresowych aktualizacji i otrzymywać je w tle, lokalny plik manifestu aplikacji internetowej (metadane spakowane w pakiecie w /.well-known/manifest.webmanifest) musi zawierać prawidłowe pole update_manifest_url.

Jeśli ten adres URL zostanie pominięty w lokalnym pliku manifestu aplikacji, niezarządzany silnik aktualizacji nigdy nie będzie przeprowadzać kontroli w tle, a aplikacja pozostanie na stałe w wersji początkowej instalacji.

Ręczny wybór kanałów

Podczas początkowej instalacji niezarządzanego IWA przeglądarka sprawdza manifest aktualizacji i wyświetla dostępne opcje kanałów (np. „Stabilny”, „Beta”) bezpośrednio użytkownikowi, jeśli deweloper skonfigurował wiele kanałów.

Kluczowe reguły cyklu życia

Pochodzenie pierwszej instalacji: niezależnie od kanału wybranego przez użytkownika podczas instalacji, początkowa instalacja zawsze wdraża pliki spakowane w dostarczonym pakiecie instalacyjnym.
Kolejne aktualizacje: po zainstalowaniu kolejne aktualizacje są pobierane wyłącznie z wybranego kanału. Aplikacja zostanie zaktualizowana tylko wtedy, gdy w przypadku danego kanału docelowego zostanie opublikowana wersja wyższa niż zainstalowana.
Przełączanie kanałów: aby po instalacji przełączyć się na inny kanał aktualizacji, użytkownik musi odinstalować IWA i zainstalować ją ponownie, wybierając wybrany kanał podczas procesu instalacji.

Testowanie wdrożeń zarządzanych

Dla administratorów zarządzających urządzeniami za pomocą konsoli administracyjnej Chrome Enterprise lub konfigurujących zasady bezpośrednio:

W ustawieniach organizacji otwórz panel Szczegóły aplikacji.
Zastosuj właściwości konfiguracji, aby przetestować przypinanie i cele kanału. Ponieważ te elementy sterujące są w pełni zgodne ze standardowymi sesjami użytkowników, zarządzanymi sesjami gości (MGS) i kioskami, możesz weryfikować zachowania we wszystkich docelowych środowiskach wdrażania.
Aby sprawdzić aktualizacje lokalnie, na kliencie testowym przejdź do chrome://web-app-internals, aby ręcznie wymusić sprawdzanie aktualizacji i przeanalizować przychodzące pakiety manifestu.

Podsumowanie

Architektura bezpieczeństwa izolowanych aplikacji internetowych została zaprojektowana tak, aby ułatwiać pracę programistom, a jednocześnie zapewniać ścisłą przewidywalność i kontrolę nad zachowaniami związanymi z cyklem życia aplikacji. Korzystając z funkcji zarządzania wersjami Chrome, zarówno deweloperzy, jak i administratorzy IT mogą tworzyć niezawodne potoki wdrażania, które są zgodne z rygorystycznymi standardami zgodności i celami operacyjnymi.

Podczas projektowania strategii aktualizacji aplikacji i zarządzania nią pamiętaj o tych podstawowych zasadach:

Używaj kanałów progresywnych: kanały aktualizacji (np. beta, dev lub niestandardowe pierścienie) umożliwiają stopniowe zbieranie danych telemetrycznych i opinii. Dzięki temu główne aktualizacje przechodzą rygorystyczną weryfikację, zanim trafią do ogółu użytkowników na kanale domyślnym.
Przypinanie dla stabilności: w wysoce ustrukturyzowanych środowiskach korporacyjnych, w których obowiązują przepisy, przypinaj krytyczne punkty końcowe do zweryfikowanej, dokładnej wersji pinned_version, aby chronić operacje przed nieoczekiwanymi awariami lub zakłóceniami przepływu pracy.
Rezerwuj obniżanie wersji na sytuacje awaryjne: pamiętaj, że obniżanie wersji jest skutecznym zaworem bezpieczeństwa, który wcześniej był niedostępny. Jednak wycofanie zmian powoduje całkowitą ponowną instalację i usunięcie całej lokalnej pamięci klienta (IndexedDB, LocalStorage, pliki cookie), dlatego powinno być zarezerwowane wyłącznie na potrzeby krytycznych działań naprawczych związanych z bezpieczeństwem. W przypadku zwykłych poprawek idealną strategią jest zawsze wdrożenie drobnej aktualizacji wyprzedzającej.
Poznaj flagi zasad: pamiętaj o przełącznikach administracyjnych. Włączenie allow_downgrades spowoduje wstrzymanie wszystkich przyszłych aktualizacji, nawet jeśli nie jest aktywnie zdefiniowany żaden przypięty element.
Zapewnij integralność bajtową: upewnij się, że identyczne numery wersji wdrożone w różnych kanałach są mapowane na identyczne pakiety, które są zgodne bajt po bajcie. Pozwoli to uniknąć nieprzewidywalnych stanów aplikacji, gdy klienci przechodzą między kanałami.

Dzięki zintegrowaniu tych funkcji bezpośrednio z plikiem manifestu aktualizacji i schematem zasad przedsiębiorstwa możesz zapewnić niezawodny, podlegający kontroli i bezpieczny proces aktualizacji, który zachowuje gwarancje wysokiego zaufania ekosystemu izolowanych aplikacji internetowych.