Управление версиями

Magdalena Skarbińska

Demián Renzulli

Изолированные веб-приложения (IWA) обеспечивают высоконадежную, безопасную и дискретную по версиям среду выполнения поверх веб-платформы. В производственных средах, особенно в управляемых предприятиях, администраторам и разработчикам необходим точный контроль над развертыванием программного обеспечения.

Для удовлетворения этих требований Chrome предоставляет комплексные возможности управления версиями для IWA, включая каналы обновлений , фиксацию версий и понижение версий . Эти функции обеспечивают предсказуемость развертывания и быстрое восстановление для всей пользовательской базы.

Доступность

Поведение системы управления версиями зависит от того, управляется ли IWA администратором или устанавливается непосредственно пользователем:

• Управляемые IWA: административные функции (включая закрепление на основе политик и понижение версии) доступны начиная с Chrome 133 .
• Неуправляемые (устанавливаемые пользователем) IWA: функции, доступные пользователю (например, ручной выбор канала), доступны начиная с Chrome 150 .

Совместимость типов сессий

Все функции управления версиями, включая каналы обновлений и закрепление версий, полностью совместимы со всеми типами сессий ChromeOS. Это включает в себя:

• Стандартные управляемые пользовательские сессии
• Управляемые гостевые сессии (MGS)
• Специализированные среды в режиме киоска

Обновить каналы

Используя каналы обновления, разработчики могут сегментировать сборки приложений для различных аудиторий развертывания и тестирования. Для настройки каналов добавьте необязательное поле массива channels к каждой записи версии в манифесте обновления приложения. Эти имена каналов не ограничены фиксированными ключевыми словами платформы (например, canary или stable ), а являются произвольными, определяемыми разработчиком идентификаторами, которые должны быть отформатированы как строчные буквы и цифры ASCII (которые могут содержать дефисы или подчеркивания, но не пробелы). Если в записи версии поле channels полностью отсутствует, Chrome неявно устанавливает для нее доступность по умолчанию канала "default". В конечном итоге, имя канала, указанное в административной политике, должно точно соответствовать строке, определенной в манифесте; любые опечатки или несоответствия в конфигурации приведут к тому, что подходящая версия не будет определена, что фактически остановит обновления для этих клиентов.

Конфигурация манифеста

Для настройки каналов добавьте необязательный массив channels к каждой записи версии в вашем Web App Manifest . Вот несколько моментов, которые следует учитывать:

• Сопоставление каналов: Если в записи версии определен массив channels , то эта версия может быть установлена ​​только на указанных каналах.
• Резервный вариант по умолчанию: если в записи версии полностью отсутствует поле channels , Chrome предполагает, что версия принадлежит исключительно к каналу default .
• Точное совпадение строк: имена каналов, указанные в конфигурациях политики на стороне клиента, должны точно совпадать со строками, определенными в манифесте обновления (с учетом регистра). Если ни одна версия не соответствует целевому имени канала, приложение не сможет найти подходящие обновления.

Пример обновления манифеста

В следующем примере показан манифест обновления, поддерживающий несколько каналов выпуска:

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

На основании данного манифеста для каждого целевого канала доступны следующие версии:

• по умолчанию: 0.2.0 , 0.4.0 (для которого отсутствует явный канал, и используется значение по умолчанию)
• дельта: 0.1.0 , 0.2.0 , 0.3.0
• бета-версия: 0.3.0

Механизм обновления IWA поддерживает выбор конкретных каналов выпуска путем поиска поля channels в манифесте обновления приложения.

Закрепление версии

В условиях высоких требований к соответствию стандартам или высокой стабильности корпоративных сред администраторы должны обеспечивать работу устройств с использованием точных версий критически важного для бизнеса программного обеспечения. Фиксация версий позволяет администраторам закрепить IWA на определенной версии, останавливая все последующие фоновые обновления. Это предоставляет предприятиям высоконадежный способ поддержания стабильных конфигураций и соблюдения строгих внутренних или отраслевых норм.

Чтобы зафиксировать изолированное веб-приложение (IWA) на определенной сборке, администраторы предприятия могут настроить свойство pinned_version в политике IsolatedWebAppInstallForceList . Эта возможность в основном управляется через интерактивные элементы управления пользовательского интерфейса в консоли администратора Google на панели сведений о приложении в соответствии со стандартным рабочим процессом установки IWA , хотя администраторы также сохраняют возможность развертывать эти значения политики напрямую, используя необработанные конфигурации JSON. После того, как администратор успешно укажет допустимую строку версии, Chrome загрузит указанный пакет и заблокирует все последующие автоматические обновления.

Особые модели поведения и ограничения

• Возобновление обновлений (открепление): Чтобы восстановить автоматические обновления, удалите свойство pinned_version или измените его значение на более новую целевую версию.
• По умолчанию понижение версии не предусмотрено: установка pinned_version на версию ниже текущей установленной не приведет к откату, если allow_downgrades явно не включен.
• Недоступные закреплённые версии: Если настроенная pinned_version отсутствует в указанном канале обновлений или старше установленной версии (при отключенной возможности понижения версии), Chrome сохранит текущую установленную версию и заблокирует любые дальнейшие обновления.
• Новые развертывания: Если IWA еще не установлен на управляемом устройстве, и указанная pinned_version не может быть получена или отсутствует в манифесте обновления, установка IWA завершится неудачей.

понижение версии

Если недавно установленное обновление вносит критическую ошибку или уязвимость, администраторам может потребоваться откатить устройства до предыдущего стабильного состояния. Chrome поддерживает понижение версии уже установленных управляемых IWA до более низкой — возможность, которая ранее была недоступна на платформе, когда разрешались только обновления до предыдущей версии.

Понижение рейтинга возможно только при соблюдении обоих следующих условий политики:

1. pinned_version установлен на допустимую, более старую версию.
2. allow_downgrades явно установлен в значение true.

Как работает понижение рейтинга

• Механизм запуска: Откаты обрабатываются во время регулярного цикла проверки обновлений (который выполняется каждые 4–6 часов).
• Внутри системы: Chrome выполняет полную переустановку IWA, используя более старый веб-пакет (.swbn), указанный в манифесте обновления.

Логика перехода между каналами

При переключении целевого канала приложения с помощью политики механизм обновления придерживается определенных правил:

Сценарий А: Переключение на канал с более ранними версиями.

• Если разрешено понижение версии: если pinned_version соответствует более старой версии в целевом канале и allow_downgrades имеет значение true, происходит откат (и локальные пользовательские данные удаляются).
• Если понижение версии запрещено: понижение версии не произойдет. Устройство останется на текущей установленной более новой версии и обновится только тогда, когда более новая версия станет доступна на новом выбранном канале.

Сценарий B: Переключение на канал с идентичной версией.

• Без изменений: если выбранный канал указывает на номер версии, равный номеру установленной в данный момент версии, Chrome не будет вносить никаких изменений в установленный пакет.
• Принцип побайтовой идентичности: разработчики должны гарантировать, что одинаковые номера версий в разных каналах содержат идентичные, совпадающие по байтам сигнатуры кода. Развертывание разных кодовых баз под одной и той же строкой версии в разных каналах может привести к неожиданным и нестабильным состояниям приложения.

Настройка административной политики

Контроль версий в корпоративной среде осуществляется с помощью централизованной платформы Google Admin Console, использующей схему политик IsolatedWebAppInstallForceList . Этими настройками можно управлять непосредственно через элементы управления пользовательского интерфейса в консоли администратора или развертывать с помощью конфигураций политик в формате JSON.
В следующем примере конфигурации административной политики демонстрируются каналы обновления, закрепление версий и понижение версий:

Представление ценности политики

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

пояснения к параметрам схемы

• channel (строка, необязательно) : Указывает Chrome оценивать только те версии, которые назначены этому каналу в манифесте обновления. Если параметр опущен, Chrome будет оценивать версию из канала "по умолчанию".
• pinned_version (строка, необязательно) : Явно фиксирует устройство на указанной строковой версии. Последующие автоматические фоновые обновления блокируются.
• allow_downgrades (логическое значение, необязательно) : Включает возможность отката. Если значение равно true и указано более старая, действительная версия pinned_version , Chrome запустит переустановку с пониженной версией. Предупреждение: установка этого параметра в значение true заблокирует все стандартные обновления, даже если поле pinned_version опущено.

Неуправляемые (устанавливаемые пользователем) IWA (от 150)

Для неуправляемых, устанавливаемых пользователем изолированных веб-приложений управление версиями осуществляется вручную пользователем:

Установочный пакет ──► Пользователь выбирает канал ──► Автоматическая проверка выбранного канала

Явное необходимое условие для автоматических обновлений

Для того чтобы установленные пользователем веб-приложения IWA могли проверять наличие и получать автоматические периодические обновления в фоновом режиме, локальный веб-манифест приложения (метаданные, упакованные внутри пакета по адресу /.well-known/manifest.webmanifest ) должен содержать допустимое поле update_manifest_url .

Если этот URL-адрес отсутствует в локальном файле манифеста приложения, механизм неуправляемого обновления никогда не будет выполнять фоновые проверки, и приложение навсегда останется заблокированным на своей первоначальной установленной версии.

Ручной выбор канала

В процессе первоначальной установки неуправляемого IWA браузер проверяет манифест обновлений и отображает пользователю доступные варианты каналов (например, «Стабильная версия», «Бета-версия»), если разработчик настроил несколько каналов.

Основные правила жизненного цикла

1. Первоначальная установка: независимо от канала, выбранного пользователем при установке, при первой установке всегда развертываются файлы, входящие в состав предоставленного установочного пакета.
2. Последующие обновления: После установки будущие обновления будут запрашиваться исключительно из выбранного канала. Приложение будет обновляться только тогда, когда в этот целевой канал будет опубликована версия выше установленной.
3. Переключение каналов: Чтобы переключиться на другой канал обновления после установки, пользователю необходимо удалить IWA и переустановить его, выбрав нужный канал в процессе установки.

Как тестировать управляемые развертывания

Для администраторов, управляющих устройствами через консоль администрирования Chrome Enterprise или настраивающих политики напрямую:

1. Перейдите в раздел «Подробности приложения» в настройках организации.
2. Примените параметры конфигурации для проверки закрепления и целевых каналов. Поскольку эти элементы управления полностью совместимы со стандартными пользовательскими сессиями, управляемыми гостевыми сессиями (MGS) и киосками, вы можете проверить их работу во всех целевых средах развертывания.
3. Чтобы проверить обновления локально, перейдите по адресу chrome://web-app-internals на тестовом клиенте, чтобы вручную принудительно запустить проверку обновлений и проанализировать входящие пакеты манифеста.

Заключение

Архитектура безопасности изолированных веб-приложений разработана для расширения возможностей разработчиков при сохранении строгой предсказуемости и контроля над поведением жизненного цикла приложения. Благодаря функциям управления версиями Chrome, как разработчики, так и ИТ-администраторы могут создавать надежные конвейеры развертывания, соответствующие строгим стандартам и операционным целям.

При разработке и управлении стратегией обновления вашего приложения помните о следующих основных принципах:

• Используйте прогрессивные каналы: каналы обновлений (например, beta , dev или пользовательские каналы) позволяют постепенно собирать телеметрию и отзывы. Это гарантирует, что крупные обновления пройдут тщательную проверку, прежде чем станут доступны широкой публике через основной канал.
• Закрепление для стабильности: В высокоструктурированных или ориентированных на соответствие нормативным требованиям корпоративных средах закрепите критически важные конечные точки на проверенной, точной версии pinned_version, чтобы защитить работу от неожиданных сбоев или нарушений рабочих процессов.
• Откат версий следует использовать только в экстренных случаях: помните, что откат версий — это мощный, корректирующий механизм, который ранее был невозможен. Однако, поскольку откат запускает полную переустановку и очищает все локальное хранилище клиента (IndexedDB, LocalStorage, cookie), его следует использовать исключительно для критически важных мер по устранению уязвимостей безопасности. Для обычных исправлений всегда идеальной стратегией является развертывание небольшого обновления, ориентированного на будущее.
• Разберитесь с флагами политики: будьте внимательны к административным переключателям; включение allow_downgrades остановит все обновления, даже если соответствующий параметр активно не задан.
• Обеспечение побайтовой целостности: гарантируйте, что одинаковые номера версий, развернутые в разных каналах, соответствуют одинаковым пакетам данных, чтобы избежать нестабильного состояния приложения при переходе клиентов между каналами.

Интегрировав эти функции непосредственно в ваш манифест обновлений и схему корпоративных политик, вы можете обеспечить надежный, проверяемый и безопасный процесс обновления, сохраняющий гарантии высокого уровня доверия, присущие экосистеме изолированных веб-приложений.