Библиотека сайта rus-linux.net
Технология подготовки релизов веб-браузера Firefox
Глава 2 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Firefox Release Engineering
Авторы: Chris AtLee, Lukas Blakk, John O'Duinn, Armen Zambrano Gasparian
Перевод: А. Панин
2.9. Выученные уроки
Как у инженеров, у нас возникает желание немедленно начать работу над исправлением очевидных технических проблем при их обнаружении. Однако, процесс подготовки релиза затрагивает несколько областей, как технических, так и не технических, поэтому очень важно быть готовым к решению и технических, и не относящихся к техническим вопросов.
Важность взаимодействия с другими заинтересованными сторонами
Важно быть уверенным, что все заинтересованные стороны понимают то, что наш хрупкий процесс подготовки релизов подвергает организацию, а также наших пользователей различным рискам. Эти риски охватывают все уровни организации, допуская потери бизнес-возможностей и изменение позиций на рынке программных продуктов, причиной которых может оказаться медленная и неустойчивая автоматизированная система подготовки релизов. Более того, возможность организации Mozilla защищать своих пользователей путем сверхбыстрого выпуска релизов приобрела большую важность по мере роста пользовательской базы, что в свою очередь сделало наш продукт более привлекательной целью для злоумышленников.
Интересным фактом можно назвать то, что некоторые люди, однажды столкнувшиеся с неустойчивой системой подготовки релизов во время своей профессиональной деятельности, приходят в организацию Mozilla с негативным отношением к подобным системам, выражающимся утверждением: "да уж, эти системы всегда работают плохо". Объяснение преимуществ, ожидаемых занимающейся бизнесом организацией при внедрении надежной масштабируемой системы автоматизированной подготовки релизов помогает любому человеку понять важность "незаметной" работы группы подготовки релизов, заключающейся в улучшении этой системы, которую мы и пытаемся выполнять.
Привлечение других групп
- Это помогло повысить осведомленность людей о том, чем различные группы на самом деле занимаются в процессе подготовки релиза.
- Это помогло людям понять, в каком случае у группы подготовки релизов есть возможность выполнить процесс быстрее, что в свою очередь мотивировало инженеров из этой группы на дальнейшее усовершенствование системы.
- Это помогло участникам других групп задуматься над тем, как они тоже могли бы улучшить процесс подготовки релизов, что было большим изменением мыслительного процесса в рамках всей организации.
- Наконец, это также позволило избавиться от непонятных команд, передаваемых между группами, которые в течение долгого времени приводили к большому количеству ненужных ожиданий, незапланированных стартов системы, а также ко многим другим серьезным нарушениям процесса подготовки релиза.
Установление четких взаимосвязей
Многие из наших "проблем при подготовке релиза" на самом деле являются проблемами людей: нарушение взаимодействия между группами; недостаточно развитые лидерские качества; а также преобладающее стрессовое состояние, утомление и тревога в в процессе подготовки chemspill-релизов. После установления четких взаимосвязей между группами для устранения этих нарушений взаимодействий между людьми, процесс подготовки наших релизов сразу же стал более плавным и взаимодействия людей из разных групп очень быстро улучшились.
Управление процессом работы
На начальных этапах реализации данного проекта мы очень часто теряли участников групп. Это само по себе очень плохо. В этой ситуации следует учитывать факт, заключающийся в отсутствии точной актуальной документации и подразумевающий то, что большая часть технических особенностей процесса подготовки релиза была документирована исключительно в устной форме, при этом мы теряли часть данной информации каждый раз, когда участник покидал группу. Нам нужно было срочно изменить сложившееся положение вещей.
Мы пришли к выводу о том, что лучшим способом повышения самосознания и демонстрации улучшения ситуации является предоставление возможности людям убедиться в том, что у нас есть план улучшения ситуации, причем эти люди в некоторой степени смогут изменять его по своему усмотрению. Мы добились этого, гарантируя резервирование времени для исправления по крайней мере одной любой! недоработки после выпуска каждого релиза. Нам удалось реализовать эту возможность путем введения непосредственно после выпуска релиза периода, длящегося в течение одного или двух дней, когда участников групп "не должны беспокоить". Незамедлительное решение мелких проблем в момент, пока о них еще помнят люди, помогло кратковременно отвлечь внимание людей для того, чтобы они впоследствии сфокусировали его на более масштабных проблемах последующих релизов. Более важным является тот факт, что данный подход дал людям ощущение контроля над своим будущим, и процесс подготовки релизов на самом деле начал выполняться более успешно.
Управление изменениями
Из-за давления рынка браузеров бизнес-модель и особенности продуктов организации Mozilla потребовали изменения процесса выпуска релизов в момент нашей работы над его улучшением. Это нестандартная ситуация, которую нужно ожидать.
Мы знали о том, что нам придется выпускать релизы с использованием действующего процесса их подготовки в то время, как мы будем внедрять новый процесс. В связи с этим нами было принято решение об отказе от создания отдельного проекта "greenfield" в процессе работы над существующими системами; мы чувствовали, что действующие системы были настолько хрупкими, что у нас буквально не останется времени на создание чего-либо другого.
Также мы с самого начала предполагали, что нам не будут полностью понятны причины некорректной работы систем. Каждое последовательное улучшение позволяло нам сделать шаг назад и проверить, не таит ли оно в себе новых сюрпризов, перед тем, как начинать работу над новым улучшением. Такие фразы, как "осушение болот", "очистка лука" и "как это вообще работало?" звучали постоянно при обнаружении сюрпризов в ходе работы над данным проектом.
Принимая все это во внимание, мы решили постоянно вносить большое количество незначительных улучшений в существующий процесс. Каждое последовательное улучшение делало следующий релиз немного качественнее. И, что более важно, каждое улучшение высвобождало немного больше времени при выпуске следующего релиза, что позволяло инженеру использовать немного больше времени для внесения следующего улучшения. Эти улучшения накапливались до достижения нами переломного момента, после чего мы начали выделять время для работы над значительными важными улучшениями. В этот момент преимущества оптимизаций процесса подготовки релизов стали действительно заметны.
2.10. Дополнительная информация
Мы действительно гордимся выполненной работой и теми возможностями, которые стали доступны организации Mozilla на новом развивающимся глобальном рынке веб-браузеров.
Четыре года назад выпуск двух chemspill-релизов в месяц был бы темой оживленного обсуждения в Mozilla. В отличие от этого, на прошлой неделе был опубликован эксплоит для сторонней библиотеки, из-за чего организации Mozilla пришлось выпустить восемь chemspill-релизов в течение двух неполных рабочих дней.
- Блог Chris AtLee
- Блог Lukas Blakk
- Блог John O'Duinn
- Блог Armen Zambrano Gasparnian
- Документация, описывающая архитектуру и принцип выполнения нашего процесса подготовки релизов с использованием системы контроля версий Mercurial
- Сборочные репозитории группы подготовки релизов. В особенности при подготовке релиза используются репозитории buildbotcustom, buildbot-configs, а также репозитории с кодом вспомогательных инструментов.
- Документ Firefox 7.0 Beta 4 Build Notes. В дополнение к коду мы документируем каждый аспект подготовки релиза. Эта ссылка ведет на документацию для версии 7.0b4, но вы можете перейти к документации для всех остальных релизов в том случае, если отредактируете строку URL соответствующим образом.
Вернуться к началу статьи.