Контроль версий и SCM в Google

Добрейшего.

Давно ищу разную информацию, касающуюся SCM в Google. Всегда ведь интересно знать, как работают крупные команды. Были разрозненные данные, и вот не так давно появился повод подытожить то, что известно. Нашелся хороший человек, который там работает, он не смог дать подробную инфу в силу NDA (что вполне понятно и ожидаемо), однако дал подсказки для раскопок общедоступных данных, за что ему спасибо.

Итак, Гугл использует Perforce. Использует практически на всех внутренних проектах. Есть сведения, что в Youtube его создатели использовали Subversion до покупки Гуглом, но наверняка сейчас их перевели на общую платформу.
Для "наружного применения" компания выдаёт все популярные open source системы. В первую очередь это git - через него идёт предоставление исходников платформы Android. Ну а Google Code предоставляет централизованный канонический Subversion и распределённые Mercurial и git (из DVCS сначала выбирали между Hg и git).

Над Perforce располагается широкая прослойка из инструментов, заточенных под работу именно на гугловыми проектами. Вплоть до того, что командой для работы с системой является не "p4", а "g4". Многие  костыли или workarounds, сделанные из-за недостатка функционала, до сих пор работают, несмотря на то, что в самом Перфорсе это уже давно реализовано. Работает старый принцип "работает - не трогай", ведь переделывать инфраструктуру - дело непростое, и зачастую очень богатое на ошибки. Так что после выхода очередной версии P4 её сначала разворачивают на отдельном оборудовании, накатывают сверху все внутренние тулзы, а уж потом, когда всё настроится и заработает, выкатывают это всем остальным.

Сам Perforce работает на системе серверов в режиме 24/7. Оно и понятно, над исходниками проектов работают круглые сутки со всех точек мира. И конечно, его сопровождением занимается выделенная команда инженеров.

Работа ведется без использования веток. Уж не знаю, чем это вызвано - сложностями работы с Перфорсом или другими соображениями - однако оно вот так. Для того, чтобы на транке не появлялись глючные изменения, их необходимо проверять перед тем, как помещать под контроль версий. Долгое время это делалось посредством обмена email-ами и работой через NFS, где расшаривалось рабочее пространство всех пользователей. Потом в 2006 году в компанию пришёл Гвидо ван Россум, создатель языка Python, и сделал систему ревью кода под названием Mondrian. Она позволяет по-прежнему инспектировать изменения до их помещения под контроль версий, но сейчас до коммита вся информация о дельте и комментариях к ней лежит в BigTable (гугловая система ранения). Конечно, удобный веб-интерфейс (Python + JavaScript) сильно упрощает работу, но вот вводить лишнюю сущность для хранения просто потому, что не принято класть изменения на ветки - по меньшей мере странно. Но - им виднее.

При этом широко используются релиз-инженеры. Судя по вакансиям, они занимаются всем, что требуется для доставки изменения от разработчика к конечному потребителю. Выпуск очередных версий систем, поддержание работы системы контроля версий, багтрекинг и всё то, что составляет инфраструктуру современного SCM.

Касательно багтрекинга и вообще процесса работы непосредственно над кодом - тут всё разнится от проекта к проекту. Вполне ожидаемо учитывая сколько разных проектов живет под крышей Гугла. Опять таки, многие проекты когда-то были отдельными компаниями, со своей инфраструктурой, так что хорошо уже то, что у них всех есть по крайней мере одна общая часть - система контроля версий.

Данные брались из разных материалов, однако основой служат 2 презентации:

• Perforce Users Conference 2010: Developing and Maintaining an Ongoing Strategic Perforce Plan at Google by Geoff Mendal.
• Google Tech Talk 2006: Mondrian Code Review On The Web by Guido Van Rossum.

Кстати, ван Россум сделал из Mondrian отдельное приложение, которые можно взгромоздить поверх Subversion и Google App Engine, называется Rietveld.

Если есть кому что добавить - велкам.

P.S. Для сравнения можно прочитать Немного об SCM в Microsoft и Windows. A Software Engineering Odyssey.

Как выбирали между Mercurial и git для Google Code

Добрейшего.

Некоторое время назад наткнулся на заметку в справке Google Code, посвященную тому, как выбирали распределённую систему контроля версий для этого проекта. Ссылка давно ждала удобного повода, но его не нашлось, так что лучше поздно, чем никогда.

С самого начала своей работы проект Google Code поддерживал только Subversion. Надо полагать, в виду его распространённости - ведь после заката CVS именно он стал стандартом де-факто среди бесплатных систем контроля версий. Проблемой выбора распределённой VCS команда озадачилась в 2008 году, в результате чего появилось вот это эссэ: Analysis of Git and Mercurial. Для тех, кто до сих пор поленился хоть немного изучить английский, есть народный перевод. Несмотря на мелкие неточности и стилистические ошибки, вполне можно понять, о чём речь.

Как видно на сайте Гугл.Кода, выбор пал на Ртутного. Причины - в тексте. Также встречал примерно следующее мнение - мол, приверженцы Subversion обитают на SourceForge, фанаты git - на github, ну и Гугл решил в чужой огород не лезть и взял под крыло Hg. Почему бы нет. К тому же, Python, на котором написана бОльшая часть Hg, весьма любим в компании.

P.S. Первый же коммент к оригинальному тексту вопрошает - почему Bazaar даже не рассматривали? Думаю, в первую очередь из-за его меньшей распространённости. Однако, прочитав очередной Bazaar hate speech, подумал, что не только поэтому :) Хотя это субъективное мнение, конечно.

Update: git таки появился среди поддерживаемых систем, не прошло и полгода: http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem

Google Wave // как не надо делать багтрекинг

Добрейшего.

Через старый уважаемый сайт набрел на статью на молодом гиковом сайте. В общем, на Хабре выложили пост про использование Google Wave в качестве багтрекера, а на RSDN выложили на него ссылку с комментариями.

Вкратце - есть команда 30 человек. Они использовали 5 лет Trac и заодно перепробовали кучу других тулов для управления задачами. Им нужен был инструмент, который позволил бы не только отслеживать задачу, но и как-то оперативно поддерживать весь поток сопутствующей информации - в первую очередь обсуждений в IM системы Jabber. В конце концов остановились на Google Wave - поскольку именно там они могут  теперь вволю трепаться о проекте и при этом там же вести информацию о задачах. Плюс ещё пару фишек разработали для Волны. Все жутко довольны, чего и всем советуют. Щастье всем даром и пусть никто не уйдет обиженным.

Что тут скажешь: разруха - она в головах, а не в клозетах. Если в команде бардак и никто не хочет взять на себя труд остановить его и взять всё под какое-то подобие контроля - жди беды. Люди будут упорно вариться в этом броуновском движении и не будут упорядочивать свою работу, даже когда проект разрастется до сотни человек и понадобятся совсем другие механизмы работы.

На RSDN автор высказался примерно в таком же ключе. Ну, и я его поддержал. Основные мысли:
- для оправдания бардака люди будут пробовать всё новые тулзы, которые будут как-то помогать поддерживать любимый уровень энтропии;
- делать из обсуждений задач полноценные артефакты процесса (т.е. присваивать обсуждению тикета статус отдельной самодостаточной единицы) - неправильно. Надо резюмировать результаты любых обсуждений и уже их аттачить в качестве комментариев к записям в системе трекинга;
- подобная система не способна нормально структурировать работу, а также получать статистику и числовые показатели.
Ну и не могу не процитировать камрада с RSDN:

Управление проектом — это чёткое понимание в каждый момент времени, где ты находишься. Из того что я вычитал, там даже близко нет "управления". Есть группа людей, которая "just for fun" занимается какой-то деятельностью. Всё это будет продолжаться, пока у кого-то хватит терпения оплачивать этот фан. Потом их разгонят, на форумах будут сообщения — "была классная контора, но потом прогнила".

Как-то так, да. Вообще, некоторые основы отслеживания задач уже были мной высказаны в заметке про основы багтрекинга, так что рекомендую перечитать её и сравнить с обоими постами.

Мой вывод: Google Wave (по крайней мере, предложенная реализация) не способен предоставить нужный уровень зрелости для отслеживания задач (багтрекинга) относительно большого проекта. Так что используйте что-то, что способствует применению правильных практик. Например, eTraxis ;)

UPDATE: Собственно, предмет споров самоустранился:
http://googleblog.blogspot.com/2010/08/update-on-google-wave.html