Джейсон Лейба выступал на QCon в Сан-Франциско в конце прошлого года, а Джез Хамбл сделал снимок подходящего слайда (я его немного поправил):

Звучит немного неуправляемо, верно? Не для них, в безумии есть метод, и все это оптимизировано для максимальной производительности разработчика, включая обзоры кода, повторное использование кода и максимально быстрый CI.

Одно монолитное дерево для 2000+ приложений?

Хотя Android изначально поддерживается в Git, основная часть исходного кода Google (или была в 2009 году) находится в одном стволе в Perforce. Это все источник всех приложений, независимо от различий в технологиях и графиках развертывания.

Как разработчик, учитывая, что вас интересует только ваше приложение, вы хотите получить только исходные файлы, необходимые для сборки и тестирования ваших двоичных файлов. Тем не менее, у Google есть, скажем, зигабайт источника при ревизии HEAD для проверки корневого каталога. Как разработчик, вы хотите установить эту проверку. Черт, вам нужно, так как ваш диск C: (или NFS-монтирование) недостаточно велик для того, чтобы извлекать HEAD без него. Подмножество означает меньше файлов на вашем диске C:, меньше исходных файлов в вашей IDE, более быструю последовательную сборку и просто более управляемым со всех сторон.

gcheckout

Настройка рабочей станции для «SandwichOrdering» (придуманное приложение) будет означать запуск gcheckout (сценария оболочки) в командной строке и передачу ему параметра SandwichOrdering. Он собирается войти в Perforce и обратиться к файлу ‘BUILD’ для SandwichOrdering. На некотором уровне это список каталогов, которые важны для построения SandwichOrdering. Возможно, это просто com/google/sandwichordering/и глубже. В этом есть глобальный аспект, который позволяет вам быть достаточно мелкозернистым.

Конечно, каждый извлеченный каталог может содержать в себе другой файл BUILD, который позволяет расширять последовательный ориентированный граф зависимостей. Таким образом, есть небольшое повторение. Скажем, SandwichOrdering требуется FooPersistence (надуманная библиотека). Команда для последнего будет поддерживать свой собственный файл BUILD, а один из SandwichOrdering просто включит его в свой. Возможно, у FooPersistence клиентская библиотека в дереве исходников — com/google/persistence/foo/client. Возможно, у него также был FooPersistenceServer =, com/google/persistence/foo/serverкоторому команда SandwichOrdering не требовала компиляции. Оба имели транзитивную зависимость от API com/google/persistence/foo/apiи включали ее с помощью объявлений BUILD.

Технология gcheckout изменила «клиент-спецификацию» Perforce, чтобы определить (и, возможно, переопределить) что-то, что было применимо к рассматриваемому разработчику и для проверки этой рабочей станции. Perforce имеет глобальную нотацию в спецификации клиента, которая включает в себя включения и исключения. Gcheckout автоматизировал изменения в спецификации клиента, и без этого разработчики рискуют ошибками копирования / вставки. Gcheckout не был выпущен как открытый исходный код.

Испортить другие команды

Если бы вторая команда проекта под названием SandwichMaker с собственным расписанием развертывания поделила 5% кода SandwichOrdering (скажем, сэндвич-POJO), то они включили бы только те источники, которые были включены в их оформление. Если одна или другая команда изменила эти POJO, это может повлиять на другую команду, и по умолчанию она не будет защищена, если не запустить сборку для обоих. Конечно Google есть решение для этого — фиксирование технологии вычислить , что полное воздействие оформленного будети сообщать об ошибках сборки (в том числе об ошибках модульных тестов) для вещей, которые разработчик сам не тестировал напрямую. Это до фактической фиксации в случае, если неясно — при попытке не была нарушена реальная сборка. Скажем, попытка регистрации показала, что это может оказать негативное влияние, и разработчик, вероятно, снова запустит gcheckout, чтобы дополнить свою существующую проверку исходным кодом затронутого проекта. Затем они смогут расширить свой набор изменений (сделать больше кода измененным) и снова отправить его без каких-либо негативных последствий во второй раз.

Просить прощения (не для разрешения)

Культура Google такова, что любой может попробовать внести изменения в любой исходный файл. Это может быть проект, который вы отслеживаете за 20% времени, или ошибка, которую вы имеете с тем, что используете, и это, безусловно, не просто исходный код, над которым вы работаете в команде. Как «владелец» определенного каталога, вы обязаны честно просматривать входящие коммиты. Даже те, кто находится за пределами вашей команды, и целесообразно потреблять их, если они хороши. Культура Google требует честной оценки в тот момент. Вы не можете отказаться от вещей на основании «мы слишком заняты» или «я хочу изменить это позже». Если участник издалека прошел все модульные тесты в коммите, сделал хорошее улучшение или исправил ошибку, есть обязанность использовать ее.

Вне Google — Бак

Группа Xooglers (бывших Googlers) с множеством новых коллег в Facebook, которые создали технологию под названием Buck . Он охватывает все рекурсивные функции системы сборки Google, описанной выше. Он не охватывает составную проверку / поднабор репо, с которым он сталкивается. Система сборки Google на самом деле не работает, она должна работать в тандеме с gcheckout. То, что я хотел бы видеть, — это инструмент проверки кассовых сборов, который позволяет для поднабора большей магистрали для Subversion:

buck-checkout https://svn.example.com/trunk/apps/SandwichOrdering.buck -d swo_workingcopy

И выполнять

buck-checkout p4://perforce.example.com/trunk/apps/SandwichOrdering.buck -d swo_workingcopy
# If only Perforce had a URL design.

Это сделало бы каталог swo_workingcopy и только для проверки фрагментов SandwichOrdering. Subverison имеет функцию Sparse Directory, которая позволит вам сделать это очень эффективно. Perforce (как упомянуто выше) также может сделать это через спецификацию клиента. Других инструментов контроля версий, особенно DVCS, не так много в их текущей версии. Как корпоративный разработчик, мне очень нравится эта функция, но ядру Linux она не нужна, поэтому Git для одного вряд ли получит функции частичной проверки, которые могут делать Subversion и Perforce. Конечно, есть Gitolite, который предоставляет некоторые возможности для доступа к Git, но я не уверен, как далеко это может зайти.

Бак в использовании в открытых источниках?

Команда Selenium переходит от CrazyFun к Баку в настоящее время. Мы перешли с Maven на CrazyFun около пяти лет назад. Maven очень ориентирован на XML, и о нем много писали. CrazyFun был действительно только для проекта Selenium и также был вдохновлен системой сборки Google. Саймон Стюарт (бывший ThoughtWorks, бывший Google) был главным действующим лицом CrazyFun и с радостью помогает Баку, находясь в Facebook.

Modern Perforce

В Perforce теперь есть инструмент Git-fusion , который позволяет разработчикам использовать Git и все его идиомы по отношению к фонду Perforce, включая возможность выполнять частичные проверки, как описано. Интерфейс Git для Perforce, который Google для себя не одно и то же — они были независимо разработаны.