Библиотека сайта rus-linux.net
Технология подготовки релизов веб-браузера Firefox
Глава 2 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Firefox Release Engineering
Авторы: Chris AtLee, Lukas Blakk, John O'Duinn, Armen Zambrano Gasparian
Перевод: А. Панин
2.2. "Отправка на сборку"
Кто может быть источником команды "отправка на сборку"?
Перед началом подготовки релиза назначается один человек, который будет нести ответственность за координацию всего процесса выпуска релиза. Этот человек должен посещать собрания, на которых координируется работа, понимать контекст всей выполненной работы, справедливо рассуждать о приоритетах ошибок, подтверждать возможность внесения запоздавших изменений, а также принимать строгие решения, заключающиеся в отклонении предложений. К тому же, непосредственно в день релиза этот человек является центром взаимодействия различных групп (разработчиков, контроля качества, подготовки релизов, разработчиков вебсайта, по связям со СМИ, по маркетингу, и.т.д.).
Различные компании используют различные термины для обозначения этой должности. Среди некоторых услышанных нами терминов есть такие, как менеджер релизов (Release Manager), инженер релизов (Release Engineer), менеджер программ (Program Manager), менеджер проекта (Project Manager), менеджер продукта (Product Manager), руководитель выпуска продукта (Product Czar), руководитель релиза (Release Driver). В данной главе мы будем использовать термин "координатор релиза" ("Release Coordinator"), так как мы считаем, что он наиболее точно отражает соответствующую роль в описанном выше процессе. Важным моментом является то, что роль и конечные полномочия выступающего в данной роли человека должны быть четко поняты всеми участниками процесса перед началом подготовки релиза вне зависимости от любых предшествующих периодов совместной работы над каким-либо проектом. В напряженной обстановке, создающейся в день релиза, важно, чтобы каждый знал, что от этого человека следует ожидать принятия решений, связанных с координацией процесса, придерживаться их и доверять им.
Координатор релиза является единственным человеком вне группы подготовки релизов, который может отправлять электронные письма для выполнения "остановки сборок" в том случае, если обнаруживается проблема, не позволяющая распространять собранный релиз. Любые отчеты о подозрительных проблемах, которые также могут препятствовать распространению релиза, перенаправляются координатору релиза, который впоследствии исследует их, примет окончательное решение о их принятии или отклонении и своевременно сообщит об этом решении всем заинтересованным сторонам. В напряженной обстановке момента сборки релиза нам всем следует ожидать принятия этим человеком связанных с координацией процесса сборки решений, придерживаться их и доверять им.
Как передать команду "отправка на сборку"?
go to build Firefox 6.0.1
Аналогично, в том случае, если в релизе обнаруживается проблема, координатор релиза передаст команду "остановить все сборки" ("all stop") в форме электронного сообщения с новой темой, отправленного в тот же список рассылки. Мы посчитали неэффективной отправку всего лишь ответа на последнее относящееся к релизу электронное сообщение; в некоторых клиентах электронной почты темы обсуждений оформляются таким образом, что пользователи не заметят сообщение с командой "остановить все сборки", так как оно будет находиться гораздо ниже в несвязанной теме.
Какая информация содержится в электронном сообщении с командой "отправка на сборку"?
- Указание на именно тот исходный код, который должен использоваться для релиза; в идеальном случае это указание должно быть строкой URL, указывающей на определенное изменение в репозитории исходного кода, на основе которого будут формироваться сборки для релиза.
- Инструкции, аналогичные "использованию новейшего исходного кода" неприемлемы ни в каком случае; при подготовке одного из релизов в момент после передачи команды "отправка на сборку" в сообщении электронной почты и до непосредственного начала процесса сборки разработчик из лучших побуждений разместил неподтвержденное изменение исходного кода в не предназначенной для изменения ветви репозитория. Это незапланированное изменение вошло в релиз. Благодаря нашей внимательности ошибка была выявлена до момента предоставления публичного доступа к релизу, тем не менее, нам пришлось задержать релиз из-за затрат времени на полную остановку процесса сборки и на выполнение повторной сборки.
- При использовании подобной CVS системы контроля версий, работающей на основе меток времени, следует явно указывать точное время; указывайте время с точностью до секунд и добавляйте к нему указание часового пояса. Во время выпуска одного из релизов в то время, когда для хранения кода Firefox все еще использовалась система CVS, координатор релиза указал граничное время изменений кода для сборки, но не указал часовой пояс. Со временем группа подготовки релизов обнаружила отсутствие информации о часовом поясе, но координатор релиза уже спал. Участники группы подготовки релизов правильно догадались, что должно было использоваться местное время (для штата Калифорния), но из-за ночной путаницы и использования часового пояса PDT вместо PST мы потеряли последнее исправление критической ошибки. Эта недоработка была выявлена группой контроля качества продукта перед предоставлением доступа к сборке широкому кругу пользователей и нам также пришлось останавливать сборку и начинать ее сначала с использованием корректного граничного времени изменений кода.
- Четкое обоснование срочности данного релиза. Хотя эта информация и кажется очевидной, она важна при работе в некоторых нестандартных ситуациях, поэтому ниже приведено краткое описание типов релизов:
- Некоторые релизы являются "обычными" релизами и могут подготавливаться в обычное рабочее время. Это ранее запланированные релизы, которые выпускаются в оговоренное время и не требуют выполнения срочной работы. Конечно же, все сборки программных продуктов для релизов должны формироваться своевременно, но от людей, занимающихся подготовкой релизов, не требуется работы в течение нескольких ночей и приложения всех сил для выпуска обычного релиза. Вместо этого мы заранее правильно планируем выпуск таких релизов, поэтому весь процесс подготовки релиза проходит в соответствии с ранее составленным графиком и люди работают над релизом в обычное рабочее время. Такой подход позволяет не загружать людей излишней работой, причем они смогут работать и в случае появления необходимости выполнения срочной незапланированной работы.
- Некоторые релизы являются chemspill-релизами, которые должны срочно подготавливаться и выпускаться в условиях, когда каждая минута на счету. Эти релизы обычно выпускаются в случае необходимости исправления ошибки, используемой опубликованным эксплоитом или в случае необходимости исправления недавно выявленной ошибки, заключающейся в аварийном завершении процесса и затрагивающей большую часть нашей пользовательской базы. Chemspill-релизы должны создаваться так быстро, как это возможно и обычно при их выпуске не используется предварительное планирование.
- Некоторые релизы могут превращаться из обычных релизов в chemspill-релизы и наоборот из chemspill-релизов в обычные релизы. Например, в том случае, если исправление безопасности из обычного релиза было непредумышленно опубликовано, обычный релиз превращается в chemspill-релиз. В том случае, если маркетинговое требование, заключающиеся в выпуске "предварительного специального релиза" для демонстрации на проходящей конференции приводит к задержке выпуска релиза по маркетинговым соображениям, релиз превращается из chemspill-релиза в обычный релиз.
- По отношению к срочности некоторых релизов разные люди могут иметь разные мнения, зависящие от их взгляда на исправления, поставляемые в рамках релиза.
В обязанности координатора релиза входит взвешивание всех фактов и мнений и вынесение решения о срочности релиза, а также взаимодействие со всеми группами и сообщение о принятом решении. В случае получения новой информации координатор релиза пересматривает решение и затем снова сообщает о новой установленной срочности релиза участникам тех же групп. В том случае, если участники некоторых групп будут считать релиз chemspill-релизом и в то же время участники других групп будут считать тот же релиз обычным релизом, взаимодействие групп может быть нарушено.
Наконец, эти сообщения электронной почты также становятся очень полезными в случае необходимости измерения времени, прошедшего с момента выпуска релиза. Хотя точность измерения времени соответствует точности обычных часов, эта информация очень полезна при установлении той области, в которой в следующий раз нужно приложить наши силы для ускорения процесса. Как говорит древняя поговорка, перед тем, как вы сможете улучшить что-либо, у вас должна быть возможность измерить это.
В течение цикла бета-тестирования браузера Firefox мы также еженедельно выпускаем релизы на основе кода из нашего репозитория mozilla-beta. Каждый из этих бета-релизов проходит обычные стадии подготовки в нашей полностью автоматизированной системе и рассматривается практически идентично нашим обычным финальным релизам. Для уменьшения количества неприятных сюрпризов в процессе подготовки релиза мы пытаемся не вносить новых не протестированных изменений в систему автоматизации выпуска релизов или инфраструктуру до момента начала сборки финального релиза.
Продолжение статьи: Использование тэгов, сборка и архивы с исходным кодом