Як розробляється Cloud Foundry

CF community logoЯ коротко розповім про процес розробки 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 все, від новачка до ЛЕП, відправляють свій код на рев'ю в 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.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.