Библиотека сайта rus-linux.net
Технология подготовки релизов веб-браузера Firefox
Глава 2 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Firefox Release Engineering
Авторы: Chris AtLee, Lukas Blakk, John O'Duinn, Armen Zambrano Gasparian
Дата публикации: 23 Апреля 2012
Перевод: А. Панин
Дата перевода: 6 Октября 2013 г.
Недавно группа подготовки релизов организации Mozilla внесла множество улучшений в технологию автоматизации выпуска релизов веб-браузера Firefox. Мы сократили требования, предусматривающие человеческое вмешательство на этапах добавления подписей и отправки уведомлений о релизе заинтересованным сторонам, а также автоматизировали многие другие небольшие выполнявшиеся вручную этапы, так как каждый выполняющийся вручную этап процесса подготовки релиза может быть источником человеческой ошибки. Принимая во внимание то, что тот процесс, который мы используем на сегодняшний день, не является идеальным, мы при любой возможности стремимся дополнительно сгладить и автоматизировать его. Нашей конечной целью является процесс, позволяющий нажать кнопку и продолжить заниматься своими делами; минимальное человеческое вмешательство позволит исключить многие проблемы и излишние действия, которые были свойственны для нашего старого частично ручного и частично автоматизированного процесса подготовки релизов. В данной главе мы изучим и опишем сценарии и принятые в отношении инфраструктуры решения, на основе которых была создана система ускоренного выпуска релизов веб-браузера Firefox, применяемая с момента выпуска Firefox 10.
Вы проследите процесс развития системы с момента появления пригодного для релиза набора изменений в системе контроля версий Mercurial до превращения этого набора в релиз-кандидат, а потом и в публичный релиз, доступный ежедневно для более чем 450 миллионов пользователей со всего мира. Мы начнем рассмотрение со сборки и добавления подписей к сборкам, после чего рассмотрим измененные партнерские и специально локализованные сборки, процесс контроля качества, а также способ генерации обновлений для каждой поддерживаемой версии, платформы и локализации. Каждый из этих этапов должен быть завершен до того момента, как релиз сможет быть размешен в сети зеркал организации Mozilla, с которых его смогут скачать наши пользователи.
Мы рассмотрим некоторые решения, которые были приняты для улучшения описанного процесса; например, наш сценарий для проверки работы функций в стандартных условиях, который помогает нам исправлять множество недоработок, заключающихся в неустойчивости программного продукта к пользовательским ошибкам; наш сценарий автоматического добавления подписи; нашу технологию интеграции процесса выпуска релизов для мобильных устройств в процесс выпуска релизов для настольных компьютеров; систему генерации патчей, в рамках которой создаются обновления, а также AUS (сервис обновления приложений - Application Update Service), благодаря которому обновления отправляются нашим пользователям, установившим различные версии программного обеспечения.
В этой главе подробно описывается процесс генерации сборок веб-браузера Firefox, которые становятся релизами. Большая часть этой главы посвящена подробному описанию важных этапов, которые встречаются в процессе подготовки релиза после запуска сборки, но также здесь описываются сложные взаимодействия, осуществляемые между рабочими группами до того, как группа подготовки релизов приступает к генерации сборок для релиза, поэтому давайте начнем с этого момента.
2.1. Рассмотрите N способов до момента подготовки релиза
Рисунок 2.1: Процесс подготовки релиза от разработки кода до команды "отправка на сборку"
В момент начала реализации проекта по усовершенствованию процесса выпуска релизов программных продуктов организации Mozilla, мы использовали в качестве исходного условия тот факт, что чем более популярным станет веб-браузер Firefox, тем у нас будет больше пользователей, а веб-браузер станет более привлекательной целью для злоумышленников, ищущих уязвимости системы безопасности для последующей эксплуатации. Также, чем более популярным станет веб-браузер Firefox, тем тем большее количество пользователей нам придется защищать от вновь и вновь появляющихся уязвимостей системы безопасности, поэтому наиболее важным аспектом становится возможность доставки исправлений для системы безопасности так быстро, как это возможно. Для такой ситуации у нас даже есть термин: "chemspill"-релиз (сокращение от "chemical spill" - "разлив химикатов"). Вместо редких выпусков chemspill-релизов в промежутках времени между регулярно планируемыми выпусками релизов, мы решили проводить планирование с учетом того, что каждый релиз может быть chemspill-релизом и спроектировали систему автоматизации в соответствии этой моделью планирования.
- Мы подводим итоги работы после выпуска каждого релиза и и ищем области, в которых работа могла быть выполнена в следующий раз более плавно, просто и быстро. Если все это возможно, мы ищем и незамедлительно до выпуска следующего релиза исправляем как минимум одну недоработку, причем не важно насколько эта недоработка значительна. Постоянное усовершенствование нашей системы автоматизации выпуска релизов подразумевает то, что мы всегда ищем новые пути для того, чтобы снизить степень вовлеченности людей в процесс и в то же время улучшить устойчивость системы и сократить время выполнения работы. Большие усилия были затрачены на то, чтобы сделать наши инструменты безопасными, таким образом "редкие" события, например, нарушения работы сети, недостаток дискового пространства или опечатки, допущенные живыми людьми обнаруживаются и обрабатываются на таких ранних этапах, как это возможно. Несмотря на то, что наша система на данный момент достаточно быстра для выпуска обычных релизов, не являющихся chemspill-релизами, мы хотим сократить риск появления в будущем релизе любой ошибки, допущенной человеком. Это особенно актуально для chemspill-релизов.
- При подготовке chemspill-релиза мы исходим из того, что чем устойчивее система автоматизации, тем меньше подвержены стрессу люди из группы подготовки релизов. Мы придерживаемся идеи, заключающейся в выполнении работы так быстро, как это возможно в спокойной обстановке и мы создали инструменты для выполнения работы в настолько безопасном и надежном режиме, насколько позволяют наши знания. Меньшая подверженность стрессу подразумевает более спокойную и тщательную работу в ходе выполнения хорошо отрепетированного процесса, что в свою очередь помогает избежать сложностей при выпусках chemspill-релизов.
- Мы создали процесс "отправки на сборку" в масштабах организации Mozilla. При подготовке обычного (не chemspill) релиза каждому участнику процесса разработки может быть предоставлена возможность обзора одних и тех же отсортированных цепочек описаний ошибок, точного установления момента применения последнего исправления и удачного тестирования, а также достижения договоренности о том, когда должны быть начаты сборки. Однако, в случае chemspill-релиза, когда минуты имеют значение, отслеживание всех особенностей ошибки вместе с чтением всех последующих подтверждений наличия ошибки и предложенных исправлений через некоторое время становится очень сложным занятием. Для снижения сложности и риска совершения ошибок организация Mozilla наняла человека, который в течение полного рабочего дня отслеживает готовность кода для "отправки на сборку". Изменение процессов в ходе выпуска chemspill-релиза рискованно, поэтому для уверенности в том, что каждый знаком с процессом выпуска релиза в ситуации, когда минуты имеют значение, мы используем один и тот же процесс подготовки к выпуску chemspill- и обычных релизов.
Рисунок 2.2: Полное распределение по времени этапов процесса подготовки chemspill-релиза, используемого в качестве примера
Продолжение статьи: Отправка на сборку