Добрейшего.
Давно ищу разную информацию, касающуюся SCM в Google. Всегда ведь интересно знать, как работают крупные команды. Были разрозненные данные, и вот не так давно появился повод подытожить то, что известно. Нашелся хороший человек, который там работает, он не смог дать подробную инфу в силу NDA (что вполне понятно и ожидаемо), однако дал подсказки для раскопок общедоступных данных, за что ему спасибо.
Итак, Гугл использует Perforce. Использует практически на всех внутренних проектах. Есть сведения, что в Youtube его создатели использовали Subversion до покупки Гуглом, но наверняка сейчас их перевели на общую платформу.
Для "наружного применения" компания выдаёт все популярные open source системы. В первую очередь это git - через него идёт предоставление исходников платформы Android. Ну а Google Code предоставляет централизованный канонический Subversion и распределённые Mercurial и git (из DVCS сначала выбирали между Hg и git).
Над Perforce располагается широкая прослойка из инструментов, заточенных под работу именно на гугловыми проектами. Вплоть до того, что командой для работы с системой является не "p4", а "g4". Многие костыли или workarounds, сделанные из-за недостатка функционала, до сих пор работают, несмотря на то, что в самом Перфорсе это уже давно реализовано. Работает старый принцип "работает - не трогай", ведь переделывать инфраструктуру - дело непростое, и зачастую очень богатое на ошибки. Так что после выхода очередной версии P4 её сначала разворачивают на отдельном оборудовании, накатывают сверху все внутренние тулзы, а уж потом, когда всё настроится и заработает, выкатывают это всем остальным.
Работа ведется без использования веток. Уж не знаю, чем это вызвано - сложностями работы с Перфорсом или другими соображениями - однако оно вот так. Для того, чтобы на транке не появлялись глючные изменения, их необходимо проверять перед тем, как помещать под контроль версий. Долгое время это делалось посредством обмена email-ами и работой через NFS, где расшаривалось рабочее пространство всех пользователей. Потом в 2006 году в компанию пришёл Гвидо ван Россум, создатель языка Python, и сделал систему ревью кода под названием Mondrian. Она позволяет по-прежнему инспектировать изменения до их помещения под контроль версий, но сейчас до коммита вся информация о дельте и комментариях к ней лежит в BigTable (гугловая система ранения). Конечно, удобный веб-интерфейс (Python + JavaScript) сильно упрощает работу, но вот вводить лишнюю сущность для хранения просто потому, что не принято класть изменения на ветки - по меньшей мере странно. Но - им виднее.
При этом широко используются релиз-инженеры. Судя по вакансиям, они занимаются всем, что требуется для доставки изменения от разработчика к конечному потребителю. Выпуск очередных версий систем, поддержание работы системы контроля версий, багтрекинг и всё то, что составляет инфраструктуру современного SCM.
Касательно багтрекинга и вообще процесса работы непосредственно над кодом - тут всё разнится от проекта к проекту. Вполне ожидаемо учитывая сколько разных проектов живет под крышей Гугла. Опять таки, многие проекты когда-то были отдельными компаниями, со своей инфраструктурой, так что хорошо уже то, что у них всех есть по крайней мере одна общая часть - система контроля версий.
Данные брались из разных материалов, однако основой служат 2 презентации:
Если есть кому что добавить - велкам.
P.S. Для сравнения можно прочитать Немного об SCM в Microsoft и Windows. A Software Engineering Odyssey.
Давно ищу разную информацию, касающуюся 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.
Если есть кому что добавить - велкам.
P.S. Для сравнения можно прочитать Немного об SCM в Microsoft и Windows. A Software Engineering Odyssey.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.