Контроль версий и 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.

Развернуто об одной ветке на каждую задачу

Добрейшего.

Периодически читаю посты из командного блога Plastic SCM - продукта, обзор которого я не так давно делал. Продукт очень интересный, поэтому стараюсь быть в курсе того, что у них происходит.
И вот публикуется очередная статья, называется Branch per task workflow explained. Как следует из названия, описывает, почему же надо придерживаться политики ветвления "одна задача - одна ветка". Предполагаемый уровень читателя - новички в области контроля версий, применяющие простые практики.
Так понравилась, что решил перевести. Думаю, многим покажется интересной, несмотря на то, что объясняются, в общем-то, простые вещи.

Итак, текст.

SCM // 6. Распределенный контроль версий

Сегодня речь пойдет о довольно спорном и в чём-то провокационном вопросе — распределенных системах контроля версий.

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

SCM // 5. Метрики и документация

Сбор метрик

Что важно для менеджера, когда перед его глазами должна развернуться вся картина происходящего в проекте? Конечно, это цифры. Для контроля над ситуацией руководитель должен видеть не только то, что имеется в настоящий момент, но и то, что было ранее. Соответственно, только имея это целостное видение, можно прогнозировать будущее проекта, корректировать сроки – в общем, вести нормальную управленческую деятельность.

При чем здесь CM? При том, что он контролирует изменения. Если учесть, что любой проект — это изменение рабочих продуктов, то через CM проходят все изменения всего проекта. Стало быть, именно средства по управлению конфигурацией ПО могут давать менеджерам видение того, как изменяется проект во времени. Обычно подобное видение выражается в виде чисел.

Какие же числовые показатели (метрики) можно получить из того, что проходит ежедневно через руки CM-инженеров?

SCM // 4. Контроль версий

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

Сегодня расскажу о том, с чем работает большинство читателей — о контроле версий.

SCM // 3. Отслеживание запросов на изменение

Продолжаю цикл заметок об основах управления конфигурацией программных средств.В этой заметке речь пойдет о том, что большинство называют bugtracking systems. Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.

Отслеживание запросов на изменение

Для начала, как вообще возникают изменения на проекте? Вариантов всего несколько:

SCM // 2. Конфигурации и baselines

Продолжаем серию заметок про SCM. Сегодня речь пойдет о следующих вещах:
— Рабочие продукты и конфигурации;
— Компонентная разработка;
— Продуктовые линейки;
— Стабилизация результатов работы;
— Baselines AKA базовые конфигурации;
— Конфигурации при компонентной разработке;
— Конфигурации при наличии продуктовых линеек.

SCM // 1. Введение в управление конфигурацией ПО

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase. В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

Потом была пара поводов, чтобы подумать о написании статей по теме. Вот и решил написать об основах того, что называется управлением конфигурацией программных средств.

Начнём

Категорически вас приветствую.

Здесь будут выкладываться материалы о Software Configuration Management. По-русски это называется Управление конфигурацией программных средств. За несколько лет работы CM-инженером накопился некоторый опыт, которым хочется поделиться с теми, кому это может быть интересно. А заодно и самому не забыть :) поскольку профессионально СМ'ом я уже не занимаюсь. Отсюда и название блога - сиэмщик я, увы, отставной, теперь это моё хобби :)

Кому интересны подробности об опыте - читайте мой профиль на LinkedIn.

Материалы также публикуются на Хабре - читайте na zdorovie.