Предисловие от оригинального автора:
В марте 2011 года я написал черновик статьи о том, как команда, отвечающая за Google Chrome, разрабатывает и выпускает свой продукт — после чего удобно об этом забыл.Сегодня я расскажу вам о том, как работает Chromium. Нет, мы не говорим о браузере.Всего несколько дней назад я случайно наткнулся на него.
Хотя в некоторых местах он может быть устаревшим (Chrome разветвил WebKit на Blink в 2013 году, и я сам больше не работаю в Google), я склонен думать, что содержащиеся в нем идеи все еще актуальны.
Хром , а скорее о Хром — группа людей, участвовавших в создании браузера.
Над проектом Chromium работают сотни инженеров.
Вместе мы фиксируем около 800 изменений в кодовой базе каждую неделю.
Мы также зависим от многих других крупных и активно развивающихся проектов, таких как V8 , Скиа И ВебКит .
Мы отправляем новую стабильную версию сотням миллионов пользователей каждые шесть недель в соответствии с графиком.
И мы поддерживаем несколько других каналов раннего доступа, которые обновляются еще быстрее: самый быстрый канал, канарейка , «тихо» автообновляется почти каждый будний день.
Как все это продолжает работать? Почему у этого «автобуса» до сих пор не отвалились «колеса»? Почему еще не все разработчики сошли с ума? С технологической точки зрения скорость работы команды Chromium достигнута благодаря надежным, эффективным и бесшумным автоматическим обновлениям.
С точки зрения человеческих ресурсов, заслуга принадлежит преданным своему делу, трудолюбивым и умным командам разработчиков ПО и разработчиков релизов, без которых весь проект развалился бы за считанные недели.
А еще дизайнеры, продакт-менеджеры, писатели, пиарщики, юристы, специалисты по информационной безопасности и все остальные, кто слаженно работает над каждым стабильным релизом.
Сегодня я не буду говорить обо всех, концентрируясь только на инженерных темах, чтобы не скатиться в гигантский пост в духе Стива Йегге.
Я собираюсь поговорить о процессе разработки Chromium, который специально разработан для обеспечения возможности быстрого выпуска релизов.
Мы поговорим об интересных находках, которые могут быть полезны другим проектам, независимо от того, как выглядит график их релизов; Я также упомяну о наших трудностях.
Без ветвей
Во многих проектах обычной практикой является создание ветки для работы над новыми «основными» функциями.Идея этого выбора заключается в том, что сбои из-за нового кода не повлияют на других разработчиков и пользователей.
Как только функция завершена, она снова сливается с ствол , за которым обычно следует период нестабильности, пока решаются вопросы интеграции.
Этот подход не будет работать с Chrome, поскольку мы выпускаем обновления каждый день.
Мы не можем допустить внезапного появления в нашем ствол большие куски нового кода, так как в этом случае велика вероятность того, что каналы обновления канарейка или разработчик надолго уйдет в отрицание.
Кроме, ствол Chrome движется вперед с такой скоростью, что разработчикам непрактично оставаться изолированными в своей ветке слишком длительный период времени.
К тому времени, как они убьют свою ветку, ствол будет выглядеть настолько по-другому, что интеграция будет трудоемкой и подверженной ошибкам.
Мы создаем ветки производства перед каждым нашим бета-релизом, но они очень недолговечны — максимум шесть недель, до следующего бета-релиза.
И мы никогда не разрабатываем непосредственно в этих ветках — все поздние исправления, которые должны быть включены в релиз, сначала делаются в ствол , после чего в ветке будет сделан выбор вишни.
Приятный побочный эффект этого процесса: для проекта нет выделенной команды разработчиков.
"Второй класс" , которые занимаются исключительно работой с оперативным подразделением.
Все разработчики всегда работают с последней актуальной версией исходного кода.
Переключатели времени выполнения
Несмотря на то, что мы не создаем ветки, нам все равно нужен способ скрыть незавершенные функции от пользователей.Естественный способ сделать это — использовать проверки во время компиляции; его проблема в том, что этот подход мало чем отличается от создания ветвей кода — по сути, у вас все еще есть две независимые базы кода, которые однажды придется объединить.
А, поскольку новый код по умолчанию не компилировался и не тестировался, разработчикам не составит труда случайно сломать этот код. Вместо этого проект Chromium использует проверки во время выполнения.
Каждая разрабатываемая функция с самого начала компилируется и тестируется на всех конфигурациях.
У нас есть флаги командной строки , который мы тестируем в самом начале; В других местах кодовая база по большей части понятия не имеет, какие функции доступны.
Эта стратегия означает, что работа над новыми функциями с самого начала интегрирована в код проекта в максимально возможной степени.
По крайней мере, новый код компилируется так, что все изменения в основном коде, которые необходимо внести для работы новой функции, проверяются, а пользователь предполагает, что все работает как обычно, и не замечает разницы.
Что ж, мы легко можем написать автоматические тесты, проверяющие работу функций, которые пока недоступны, временно.
«переопределение» командной строки .
Когда функция приближается к завершению, мы представляем опцию в виде флага в хром://флаги , чтобы опытные пользователи могли начать его тестирование и оставить нам отзыв.
В результате, когда мы считаем, что функция готова к выпуску, мы просто удаляем флаг командной строки и делаем ее доступной по умолчанию.
К этому моменту код обычно уже протестирован вдоль и поперёк, а также запущен многими пользователями, так что потенциальный ущерб от его активации минимизирован.
Огромное количество автоматизированного тестирования
Чтобы выпускать релизы каждый день, нам необходимо следить за тем, чтобы наша кодовая база всегда была в хорошей форме.Для этого нужны автоматизированные тесты, и очень большое их количество.
На момент написания этой статьи в Chrome было 12 000 тестов на уровне юнит-класса, 2 000 автоматизированных интеграционных тестов, а также огромный набор тестов производительности, тестов на раздувание, тестов потокобезопасности и безопасности памяти и, возможно, многих других в будущем.
Я сейчас не помню.
И все это только для одного Chrome; WebKit, V8 и остальные наши зависимости тестируются независимо; Только в WebKit имеется около 27 тысяч тестов, проверяющих правильность отображения и функционирования веб-страниц.
Наше основное правило: каждое изменение должно сопровождаться испытаниями.
Мы используем общедоступные билдбот , который постоянно запускает новые изменения в нашем коде на тестовом наборе ( тестирование ).
Мы придерживаемся политики «зеленого дерева»: если изменение «ломает» тест, то он немедленно откатывается, и разработчик должен зафиксировать изменения и повторно загрузить их.
Мы не оставляем такие «ломающие» изменения в дереве, потому что:
- Это позволяет случайно внести еще больше «ломающих» изменений — если дерево уже красное, то никто не заметит, когда оно станет еще краснее.
- Это замедляет разработку, поскольку каждый будет вынужден работать над чем-то сломанным.
- Это побуждает разработчиков вносить небрежные быстрые исправления для прохождения тестов.
- Это мешает нам выпустить!
Результаты отправляются по электронной почте разработчику.
У нас также есть очередь фиксации , который служит для проверки изменения и автоматического его применения, если все тесты пройдены.
Мне нравится использовать его после долгой ночи взлома — я нажимаю кнопку, ложусь спать и через некоторое время просыпаюсь с надеждой, что мои изменения были внедрены.
Благодаря автоматическому тестированию, которое мы проводим, мы можем обойтись минимальным ручным тестированием на нашем канале.
разработчик , а на "канарейках" его вообще не проводят.
Безжалостный рефакторинг
Поскольку у нас довольно обширное тестовое покрытие, мы можем позволить себе агрессивный подход к рефакторингу.Проект Chrome постоянно работает над рефакторингом по нескольким основным направлениям — например, на период 2013 года это были Карнитас И Аура .
При наших размерах и темпах важно поддерживать чистоту и простоту понимания кодовой базы.
Для нас эти качества важнее, чем предотвращение регрессов.
Инженеры проекта Chrome имеют право вносить улучшения в любую часть системы (однако мы можем запросить обязательную проверку у владельца модуля).
Если в результате рефакторинга что-то сломается, и это невозможно обнаружить на этапе тестирования, то с нашей точки зрения это вина не инженера, проводившего рефакторинг, а того, чья фича не была реализована.
достаточно покрыты тестами.
ДЕПС
WebKit развивается столь же быстрыми темпами.И точно так же, как мы не можем позволить себе иметь ветки для функций, которые однажды внезапно сольются с основной, мы не можем позволить себе попытаться объединить все изменения WebKit за месяц, так как это дестабилизирует дерево для несколько дней.
Вместо этого мы пытаемся скомпилировать Chrome вместе с последней версией WebKit (почти всегда этой версии меньше полудня), пока не добьемся успеха.
В Корень проекта Chrome существует файл, содержащий версию WebKit, с которой он теперь успешно компилируется.
Когда вы оформляете заказ и создаете рабочую копию или обновляете исходный код Chrome, инструмент gclient автоматически получает версию WebKit, указанную в файле.
Каждый день, несколько раз в день, инженер обновляет номер версии, выясняет, не возникли ли новые проблемы при интеграции, и передает ошибки соответствующим инженерам.
В результате мы всегда получаем небольшие изменения в WebKit сразу, и при таком подходе влияние на наше дерево исходников обычно минимально.
Мы также добавили ботов в buildbot WebKit, чтобы, когда инженеры WebKit вносят изменения, которые нарушают работу Chrome, они сразу же узнают об этом.
Большим преимуществом системы DEPS является то, что мы можем очень быстро вносить изменения в нашу веб-платформу.
Функция, представленная в WebKit, станет доступна пользователям Chrome на канале канарейка всего за несколько дней.
Это побудило нас внести улучшения непосредственно в исходную версию WebKit, где они будут полезны всем, кто использует WebKit в своих приложениях, а не применять их локально в Chrome. Честно говоря, наше главное правило — мы вообще не вносим никаких локальных изменений в WebKit (как и в остальные проекты, от которых зависит Chrome).
Проблемы
Тщательное тестирование остается нерешенной проблемой.В частности, «нестабильные» интеграционные тесты ( нестабильные интеграционные тесты ) стали для нас постоянной проблемой.
Chrome — большой, сложный, асинхронный, многопроцессный и многопоточный проект. Таким образом, интеграционные тесты могут легко провалиться из-за тонких проблем со временем, которые случаются время от времени.
В проекте нашего размера тест, который проваливается в 1% случаев, гарантированно провалится несколько раз в день.
Как только тест становится «нестабильным», команда быстро привыкает его игнорировать, в результате чего легко пропустить провал другого, работающего теста для того же участка кода.
Поэтому мы склонны отключать «нестабильные» тесты и терять процент покрытия, что упрощает предоставление пользователю информации о серьезных регрессиях.
Другая проблема в том, что на такой скорости становится сложно «приукрасить».
На мой взгляд, команде проще уловить все детали в редких «громких» релизах, чем пытаться сохранять и постоянно поддерживать фокус на каждой детали в течение неопределенного периода времени.
Поскольку тестирование мелких деталей, таких как расстояние между кнопками на панели инструментов, часто может быть затруднительным, в таких местах могут легко закрасться ошибки.
Наконец, мне кажется, что стресс – это вполне реальная проблема.
При всем этом постоянно меняющемся коде, даже если человек пытается сосредоточиться только на своей зоне ответственности, это не значит, что на него не повлияет что-то, происходящее в другой части проекта.
Если вы постоянно пытаетесь поддерживать работоспособность своей части Chrome, рано или поздно вы начнете чувствовать, что живете на вулкане и не можете позволить себе ни минуты покоя.
С последней проблемой мы боремся, разбивая кодовую базу на основные модули.
Инженеры Carnitas пытаются создать более четкие и тесные интерфейсы между некоторыми из наших основных компонентов.
На данный момент большая часть кода стала чище и понятнее, но пока рано говорить, насколько это поможет снизить нагрузку на глобальном уровне.
Окончательно
Так почему же колеса до сих пор не отвалились? Короче говоря: благодаря жизни без ветвей, переключениям во время выполнения, множеству автоматических тестов, безжалостному рефакторингу и поддержанию как можно ближе к HEAD наших зависимостей.Эти методы будут наиболее полезны для крупных проектов, которые имеют быстро меняющиеся исходные зависимости, но возможно, что некоторые из них будут применимы и к более мелким проектам.
Теги: #Chromium #Тестирование ИТ-систем #Google Chrome #браузеры
-
Из Истории Торговли Приглашениями
19 Oct, 24 -
Организация Ароматов Во Flutter
19 Oct, 24 -
Toshiba W100 — Буклет С Windows 7
19 Oct, 24
