Как разрабатывается Cloud Foundry
Я кратко расскажу о процессе разработки Cloud Foundry (CF), особенностях open source модели и немного личного опыта.
В 2013 году я стал активным пользователем платформы, когда IBM запустила внутреннюю бету Bluemix, в начале этого года я принял участие в портировании Cloud Foundry на архитектуру POWER8, а с середины октября я стал членом CF core team, пройдя CF Dojo. Но обо всем по порядку.
Не буду углубляться в историю или объяснять что такое Cloud Foundry, но вот необходимый минимум фактов. CF — это Platform as a Service (PaaS), разработанная VMWare и позднее переданная Pivotal Software. Исходный код был открыт, сейчас еще есть отдельный инкубатор CF проектов. Чуть позже была создана Cloud Foundry Foundation, в которую вошли Pivotal, IBM, VMWare, EMC, GE, Intel, SAP, настоящее время в нее входит более 50 организаций. Изначально платформа была написана на Ruby, позднее часть компонент были переписаны на Go.
Теперь продолжу мою историю. Весной у нас уже была немного работающая версия CF на POWER8 и мы решили поделиться нашим кодом с сообществом. Сделали pull request для одного из компонент (BOSH) и стали ждать. Но ничего не происходило. У меня был некоторый опыт разработки OpenStack и там все было живее, рано или поздно кто-то приходил в твой патч в Gerrit, комментировал, ставил оценку, ты обновлял патч, пару месяцев — и твои две строчки в апстриме! Если везло, то можно было и за пару недель успеть. Вобщем мы стали разбираться и поняли следующее.
В CF используется другая модель open source. Если в OpenStack все, от новичка до PTL, отправляют свой код на ревью в Gerrit, собирают свои два +2 от core team members и страются не получить -1 от остальных, то в CF есть два уровня доступа. Есть core team, работающая полный рабочий день над конкретными задачами, вот, например, трекер команды BOSH. Это сотрудники компаний, входящих в Cloud Foundry Foundation, некоторые из них имеют прямой доступ к git репозиторию. Остальные работают через pull requests, некоторые из которых обрабатываются быстрее, чем обычные, я ниже расскажу почему. Формальной системы code review нет по той же причине.
Дело в том, что CF использует agile процесс, основными элементами которого являются TDD и парное программирование. Да, парное программирование, помните XP? Не Windows XP, а eXtreme Programming. Core team работает именно так и эта модель рекомендована для всего сообщества. Очевидно, это предъявляет специфические требования к индивидуальным контрибьюторам, поэтому команда CF ставит на обучение и доверие, а не фильтрацию через code review. Для этого была создана программа Cloud Foundry Dojo.
Доджо — это место, где японцы занимаются боевыми искусствами, но в CF Dojo драться не придется. Эта программа открыта для членов сообщества, участие бесплатно. Сама программа крайне просто устроена — новый разработчик (желательно пара) минимум 6 недель работает вместе с членами команды CF. Через 3 недели он или она получает отзыв от новых коллег о том что можно улучшить, через 6 недель, если команда видит прогресс, он или она получает черный пояс. На самом деле не получает. Получает некоторый кредит доверия и изменения от этого разработчика гораздо быстрее принимаются командой, более того, он или она становится частью команды и может работать над общими задачами.
Я проходил CF Dojo в офисе Pivotal в Сан Франциско. Еще один зал недавно открыла EMC в Кембридже, Массачусетс. IBM скоро открывает свой в Research Triangle Park. Обычно работаешь в одной команде, в моем случае это был BOSH, компонент управляющий кластером. Команды стандартного размера, 6–12 разработчиков, один product manager. Между командами есть ротация, поэтому существует старейшина — якорь (anchor), разработчик, который редко (или никогда) покидает команду. Неделя начинается с Iteration Planing Meeting (IPM), заканчивается Retrospective Meeting. На первом менеджер продукта рассказывает что нужно будет сделать, на втором команда говорит что пошло не так, а что было сделано правильно. Каждый день начинается со Standup Meeting, где каждый рассказывает что было сделано вчера, что будет сегодня и какие есть проблемы. Вобщем, более-менее обычный Scrum. На standup команда разбивается на пары.
Пара садится за пару маков, которые ведут себя как один. Все машины в офисе одинаковой конфигурации, личных почти нет. У многих разработчиков свои клавиатуры, в остальном все общее, такой дзен. Пара берет первую свободную историю (user story) из трекера и начинает, нет, не писать код. Сначала пишутся тесты, обычно unit, но часто и integration. Потом пишется код. Код должен минимально решать задачу и пройти тесты. Потом делается рефакторинг, чтобы было не стыдно. В итоге изменения комитятся напрямую, без code review. Их подхватывает CI (используется собственная разработка Concourse и немного Jenkins, если интересно зачем было писать свое, почитайте). Если код не прошел пайплайн, пара вносит исправления. Когда все стало зеленым, история отправляется к менеджеру продукта, который может принять ее или вернуть на доработку. В итоге изменения попадают в следующую версию компонента, которая создается раз в несколько дней. Пары меняются раз в 1–3 дня, иногда смена бывает, когда работа над историей еще не закончена. Также нет специализации разработчиков, например кто-то занимается только OpenStack, а кто-то AWS — такого нет в принципе, истории распределяются достаточно случайно. Один день пишешь на Ruby, завтра на Go, потом правишь shell скрипты для CI или конфигурируешь AWS.
Я постарался все кратко описать, есть еще много красочных деталей, но они не так интересны всем, могу ответить на конкретные вопросы. Как видно, модель CF требует гораздо более глубокого погружения, осознанно жертвуя массовостью. Каждый подход имеет свои плюсы и минусы. Конечно, это не значит, что для weekend warriors невозможно принять участие в разработке CF, читайе код, находите задачи и шлите pull requests.
