Библиотека сайта rus-linux.net
Технология подготовки релизов веб-браузера Firefox
Глава 2 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Firefox Release Engineering
Авторы: Chris AtLee, Lukas Blakk, John O'Duinn, Armen Zambrano Gasparian
Перевод: А. Панин
2.3. Использование тэгов, сборка и архивы с исходным кодом
Рисунок 2.3: Автоматизированная расстановка тэгов
При подготовке к началу процесса автоматизации системы мы приступили к использованию сценария release_sanity.py, который был разработан интерном, проходящим летнюю стажировку в группе подготовки релизов. Этот сценарий на языке Python помогает подготавливающему релиз участнику группы, производя двойную проверку соответствия конфигурации релиза конфигурациям инструментов и репозиториев. Он также устанавливает выбранные ревизии исходного кода для релиза из ветки mozilla-release и все поставляемые в рамках этого релиза (человеческие) языки, на основе которых будут сгенерированы сборки для выпуска релиза и пересборки с поддержкой определенных языков.
Сценарий принимает файлы конфигурации системы непрерывной интеграции buildbot для любых конфигураций релиза, которые будут использоваться (таких, как конфигурации для сборки версий для настольных компьютеров и мобильных устройств), указание на ветвь в репозитории исходного кода для поиска (т.е., mozilla-release), номер сборки и версию, а также названия продуктов, которые будут собраны (такие, как "fennec" или "firefox"). Его выполнение завершится неудачей в том случае, если конфигурации репозиториев кода для формирования релизов не совпадают с заданной конфигурацией, если наборы изменений в репозитории файлов локализации не совпадают с поставляемыми нами наборами изменений файлов локализации или в том случае, когда версия и номер сборки не совпадают с переданными нашим инструментам сборки параметрами в форме тэга на основе номеров продукта, версии и сборки. В том случае, если все проверки из сценария завершатся успешно, он произведет повторную конфигурацию мастер-сервера системы buildbot, на котором выполняется сценарий и который будет управлять системами сборки релизов, после чего генерирует команду "отправка изменений" ("send change"), которая запускает автоматизированный процесс подготовки сборки.
После того, как участник группы подготовки релиза запускает системы для сборки, первым автоматически выполняемым шагом в процессе подготовки релиза Firefox является установка тэга во всех используемых репозиториях исходного кода для записи номера ревизии данных из репозиториев исходного кода, языков и связанных инструментов, которые были использованы для подготовки данной версии и сборки релиз-кандидата. Эти тэги позволяют нам отслеживать историю версий и номеров сборок релизов Firefox и Fennec (мобильной версии Firefox) в рамках наших репозиториев для релизов. Для релизов Firefox примером установленного тэга может служить FIREFOX_10_0_RELEASE FIREFOX_10_0_BUILD1 FENNEC_10_0_RELEASE FENNEC_10_)_BUILD1.
При подготовке каждого отдельного релиза Firefox используется код в среднем из 85 репозиториев системы контроля версий, которые хранят такие данные, как код программного продукта, строки локализации, код системы автоматизации для выпуска релизов, а также код вспомогательных утилит. Присвоение тэгов коду из всех этих репозиториев критически важно, так как необходима гарантия того, что на следующих этапах работы системы автоматизации выпуска релизов будут выполняться действия с тем же набором ревизий данных.
Такой подход также имеет ряд других преимуществ: команды разработчиков дистрибутивов Linux и другие участники процесса разработки могут самостоятельно повторять процесс сборки, используя тот же самый код и инструменты, что и в случае подготовки официальных сборок, а также производится запись ревизий исходного кода продукта и инструментов, используемых в ходе подготовки каждого релиза, на основе данных которой в будущем возможно сравнение изменений, осуществленных между релизами.
Как только во всех репозиториях выделены ветви и созданы тэги, группа зависимых сборочных систем автоматически начинает работу: выделяется по одной сборочной системе для каждой платформы, а также для подготовки архива исходного кода, включающего весь исходный код, используемый в релизе. Архив исходного кода и собранные установщики загружаются в директорию для релизов по мере доступности. Это позволяет любому человеку ознакомиться с тем, какой именно код был использован для формирования релиза, а также появляется возможность использовать архив исходного кода для повторной сборки в том случае, когда появится такая необходимость (например, в случае какого-либо сбоя нашей системы контроля версий). Для создания архива исходного кода Firefox нам иногда приходится импортировать код из репозитория, предназначенного для подготовки более ранних версий. Например, в случае выпуска бета-релиза происходит извлечение подписанной ревизии из репозитория Mozilla-Aurora (нашего репозитория исходного кода, отличающегося большей стабильностью, чем репозиторий для подготовки ночных сборок) для версии Firefox 10.0b1.
В случае выпуска релиза происходит перемещение подтвержденных изменений из репозитория Mozilla-Beta (практически с тем же кодом, который использовался для подготовки версии 10.0b6) в репозиторий Mozilla-Release. Позднее ветвь для выпуска релиза создается в форме именованной ветви, родительским набором изменений которой является подписанная ревизия, предназначенная для "отправки на сборку" и предоставленная координатором релиза. Ветвь для выпуска релиза может быть использована для выполнения специфичных для релиза модификаций исходного кода, таких, как увеличение номеров версий или завершение формирования списка локализаций, которые будут собраны. В будущем при обнаружения критической проблемы безопасности и необходимости ее немедленного исправления, на основе этой ветви для выпуска релиза может быт сформирован содержащий минимальное количество изменений для исправления уязвимости chemspill-релиз, после чего будет сгенерирована и выпущена новая версия Firefox.
Когда нам понадобится произвести второй цикл сборок определенного релиза под названием buildN, мы используем эти ветви для выпуска релиза с целью получения того же кода, который был подписан для "отправки на сборку", при этом любые изменения в коде релиза будут размещаться именно в этой ветви. Автоматизированный процесс сборки начинается снова с создания тэгов для нового набора изменений в ветви для подготовки релиза. В ходе выполнения нашего процесса присвоения тэгов производится большое количество операций с локальными и удаленными репозиториями исходного кода системы контроля версий Mercurial. Для упрощения некоторых из наиболее часто выполняемых операций мы разработали несколько вспомогательных инструментов: retry.py и hgtool.py. Сценарий retry.py является простой оболочкой, которая получает переданную команду и выполняет ее, пытаясь в течение нескольких раз повторить выполнение в случае неудачи. Он также следит за возникновением исключительных условий при выводе результатов выполнения команд и повторно выполняет команды, либо выводит сообщения в подобных случаях. Мы посчитали удобным решением выполнение при посредничестве сценария retry.py большей части команд, которые могут завершиться неудачей из-за внешних зависимостей.
При присваивании тэгов операции системы контроля версий Mercurial могут завершиться неудачей в случае временной неработоспособности сети, неработоспособности веб-серверов или временной чрезмерной нагрузки на используемый сервер системы Mercurial. Возможность автоматического повтора этих операций и продолжения выполнения работы сохраняет очень много нашего времени, так как нам не приходится вручную восстанавливать и удалять результаты неудавшейся попытки сборки, после чего снова запускать автоматизированную систему подготовки релизов.
Сценарий hgtool.py является утилитой, инкапсулирующей некоторые стандартные операторы системы Mercurial, такие, как операторы клонирования, операторы извлечения и обновления данных репозитория, при этом позволяющей выполнять их в ходе однократного запуска. Он также добавляет поддержку расширения для разделения данных системы Mercurial, которое широко используется нами для предотвращения появления нескольких клонированных копий репозиториев в различных директориях одной и той же машины. Добавление поддержки разделяемых локальных репозиториев значительно ускорило наш процесс присвоения тэгов, так как большинство полностью клонированных репозториев с кодом продукта и данными локализации могли быть исключены из процесса. Важной мотивацией для разработки подобных инструментов является предоставление возможности тестирования системы автоматизации настолько, насколько это возможно. Так как такие инструменты, как hgtool.py являются небольшими утилитами для выполнения единственной задачи, созданными на основе многократно используемых библиотек, их гораздо проще тестировать в изолированном окружении.
На сегодняшний день наш процесс присвоения тэгов состоит из двух параллельныо выполняемых процессов: первым является процесс присвоения тэгов версии Firefox для настольных компьютеров, который длится около 20 минут, так как предусматривает присвоение тэгов данным в более чем 80 репозиториях локализаций, а вторым является процесс присвоения тэгов данным мобильной версии Firefox, который занимает около 10 минут, так как для мобильных релизов на данный момент доступно меньшее количество локализаций. В будущем мы хотели бы ускорить наш процесс автоматической подготовки релизов, поэтому мы хотим присваивать тэги данным во всех различных репозиториях в параллельном режиме. Начальная сборка программных продуктов может запускаться тогда, когда данным в репозиториях с кодом продукта и кодом требуемых для сборки инструментов будут присвоены тэги без необходимости ожидания присваивания тэгов данным во всех репозиториях локализаций. В момент завершения этих сборок данным в остальных репозиториях будут также присвоены тэги, поэтому пакеты локализаций смогут быть подготовлены и следующие шаги процесса сборки смогут завершиться. Мы ожидаем, что эти мероприятия помогут уменьшить общее время подготовки сборок примерно на 15 минут.
Продолжение статьи: Повторно упакованные сборки с локализацией и партнерские повторно упакованные сборки