Библиотека сайта rus-linux.net
Технология подготовки релизов веб-браузера Firefox
Глава 2 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Firefox Release Engineering
Авторы: Chris AtLee, Lukas Blakk, John O'Duinn, Armen Zambrano Gasparian
Перевод: А. Панин
2.6. Обновления
Обновления создаются для того, чтобы пользователи с помощью встроенной системы обновления могли быстро и просто перейти к использованию новейшей версии Firefox без необходимости загрузки и запуска отдельного установщика. Загрузка пакета обновления происходит быстро и незаметно для пользователя в фоновом режиме. Только после того, как файлы обновления загружены и готовы для применения, Firefox предложит пользователю обновить установленную версию приложения и перезапустить его.
Сложность состоит в том, что мы генерируем очень много обновлений. Для серий релизов линии продуктов мы генерируем обновления, которые могут быть применены по отношению ко всем предыдущим поддерживаемым релизам серии для перехода к использованию новейшего релиза для данной линии продуктов. Для Firefox наличие новейшего релиза (LATEST) подразумевает необходимость генерации обновлений для каждой платформы, каждой локализации и каждого установщика, начиная с версий Firefox LATEST-1, LATEST-2, LATEST-3, ... в полной и частичной формах. В данный момент мы выпускаем обновления для нескольких различных линий продуктов.
Наша система автоматизации процесса генерации обновлений модифицирует конфигурационные файлы обновления каждой из сборок релиза ветви для поддержания в актуальном состоянии нашего простого списка соответствия между номерами версий, платформами и локализациями, для которых должны быть созданы обновления, позволяющие пользователям перейти на новый релиз. Мы предоставляем обновления в форме "фрагментов" информации. Как вы увидите в примере ниже, этот фрагмент информации является простым файлом в формате XML, расположенным на нашем сервере AUS (службы обновления приложения - Application Update Service), который информирует браузер Firefox на стороне пользователя о том, где расположены полные или частичные архивы обновлений в форме файлов с расширением .mar (архив Mozilla - Mozilla Archive).
Важные и незначительные обновления
|
<updates> <update type="minor" version="7.0.1" extensionVersion="7.0.1" buildID="20110928134238" detailsURL="https://www.mozilla.com/en-US/firefox/7.0.1/releasenotes/"> <patch type="complete" URL="http://download.mozilla.org/?product=firefox-7.0.1-complete&os=osx&lang=en-US&force=1" hashFunction="SHA512" hashValue="7ecdbc110468b9b4627299794d793874436353dc36c80151550b08830f9d8c5afd7940c51df9270d54e11fd99806f41368c0f88721fa17e01ea959144f473f9d" size="28680122"/> <patch type="partial" URL="http://download.mozilla.org/?product=firefox-7.0.1-partial-6.0.2&os=osx&lang=en-US&force=1" hashFunction="SHA512" hashValue="e9bb49bee862c7a8000de6508d006edf29778b5dbede4deaf3cfa05c22521fc775da126f5057621960d327615b5186b27d75a378b00981394716e93fc5cca11a" size="10469801"/> </update> </updates> |
Рисунок 2.6: Пример фрагмента информации об обновлении
Как вы можете увидеть на Рисунке 2.6, фрагменты информации об обновлениях содержат атрибут type, который может иметь либо значение major (важное), либо значение minor (незначительное). Незначительные обновления позволяют пользователям перейти к использованию новейшей доступной версии установленного релиза; например, незначительные обновления позволят всем пользователям релиза 3.6.* перейти к использованию новейшей подверсии для релиза 3.6, всем пользователям бета-версии разрабатываемого релиза - перейти к использованию новейшей бета-версии, всем пользователям ночных сборок - перейти к использованию новейшей ночной сборки, и.т.д. Наиболее часто выпускаются именно незначительные обновления, которые не требуют от пользователя какого-либо вмешательства в процесс обновления помимо подтверждения намерения выполнения обновления и перезапуска браузера.
Важные обновления используются тогда, когда нам необходимо сообщить пользователям о том, что доступен новейший усовершенствованный релиз, причем в этом случае будет выведено сообщение "Доступна новая версия Firefox, желаете установить обновление?", а также рекламная страница, описывающая наиболее важные функции нового релиза. Внедрение нашей новой системы ускоренного выпуска релизов позволило прекратить выпуск большого количества важных обновлений; у нас появилась возможность прекращения генерации важных обновлений с момента окончания срока поддержки релиза 3.6.*.
Полные и частичные обновления
Во время сборки мы генерируем "полное обновление" в виде файлов с расширением .mar, которые содержат все файлы нового релиза, сжатые с помощью компрессора bz2, после чего добавленные в файл архива с расширением .mar. Как полные, так и частичные обновления автоматически загружаются по каналу доставки обновлений, в котором регистрируется установленная пользователем копия приложения Firefox. Мы используем различные каналы обновлений (то есть, пользователи релизов ожидают обновлений на канале для обновления релизов, пользователи бета-версий ожидают обновлений на канале для обновления бета-версий, и.т.д.), поэтому мы можем доставлять обновления, например, для пользователей релиза и пользователей бета-версии в различное время.
Файлы с расширением .mar частичных обновлений создаются путем сравнения файлов с расширением .mar для устаревшего релиза с файлами с расширением .mar для нового релиза и создания файла "частичного обновления" с расширением .mar, содержащего данные различий в бинарной форме для любых измененных файлов, а также файл манифеста. Как вы можете увидеть в примере фрагмента информации об обновлении на Рисунке 2.6 такой подход позволяет значительно сократить размер файлов частичных обновлений. Это очень важно для пользователей, работающих с медленными соединениями с Интернет или с соединениями с Интернет, реализованными по технологии dial-up.
В устаревших версиях нашей системы автоматизации процесс генерации частичных обновлений для всех локализаций и платформ мог длиться до семи часов для одного релиза, так как выполнялась этапы загрузки файлов полных обновлений с расширением .mar, поиска различий и упаковки данных частичных обновлений в файл с расширением .mar. В конечном счете было установлено, что даже для различных платформ многие изменения компонентов выполнялись идентично, следовательно многие данные различий могли быть повторно использованы. С помощью сценария, который кэшировал хэши для каждой части данных различий, время выполнения нашего процесса генерации обновлений сократилось примерно на 40 минут.
После того, как фрагменты информации об обновлениях загружаются и размещаются на сервере автоматической системы обновлений, шаг проверки наличия обновлений заключается в а) тестовой загрузке фрагментов информации об обновлениях и б) запуске системы обновления приложения для полученного файла с расширением .mar для подтверждения корректности применения обновлений.
Генерация файлов частичных обновлений с расширением .mar, как и фрагментов информации об обновлениях на данный момент начинается после завершения процесса добавления электронных подписей. Мы выполняем действия в такой последовательности из-за того, что генерация частичных обновлений должна выполняться для файлов двух подписанных релизов и, следовательно, генерация фрагментов информации об обновлениях должна быть задержана до момента доступности подписанных сборок. Как только у нас появится возможность интеграции процесса добавления электронных подписей в процесс генерации сборок, мы сможем генерировать частичные обновления непосредственно после завершения процесса генерации сборки или повторной упаковки. Вместе с усовершенствованиями программного обеспечения нашей системы автоматического обновления, мы получим возможность размещать на зеркалах законченные сборки и повторно упакованные сборки непосредственно после завершения процесса генерации сборок. Это обстоятельство позволяет эффективно осуществлять создание обновлений в параллельном режиме, сокращая общее время их создания на несколько часов.
Продолжение статьи: Размещение сборок на внутренних зеркалах и контроль качества