Мы представляем четвертое из серии интервью с техническими руководителями проекта OpenStack в блоге Mirantis. Наша цель — обучить более широкое сообщество технических специалистов и помочь людям понять, как они могут внести вклад в проект OpenStack и извлечь из него выгоду. Естественно, ниже изложена точка зрения интервьюируемого, а не компании Mirantis.
Ниже мы представляем интервью Тьерри Карреса (Thierry Carrez), председателя технического комитета OpenStack и менеджера по релизам.
Mirantis: Расскажите о себе.
Тьерри Каррес: Конечно! Мне в этом году исполнилось 40 лет. Я живу вместе с женой и двумя детьми в небольшой деревушке в центре Франции.
Q: Очень мило. Замечаете ли вы культурные различия у разработчиков из разных точек мира?
A: Да, эти различия бросаются в глаза, и одна из задач глобального сообщества – сформировать единое целое, которое преодолевает их. Кроме этого, существуют различия, происходящие из многообразия профессионального опыта, так что дело не только в географии.
Q: Можете ли вы привести пример? В Восточной Европе, например, отзывы о коде воспринимаются как критика или неодобрение – хотя на самом деле такие отзывы призваны помочь разработчикам улучшить код.
A: Также бывают проблемы с восприятием оценки кода “-1″ в Японии, например. Также разработчики, пришедшие из больших компаний, боятся видеть свое имя, указанное явно и постоянно, рядом с изменением в коде. Это удерживает их от полного участия в сообществе разработчиков. Для тех разработчиков, которые начинали в проектах с открытым кодом или в стартапах, прозрачность — не проблема, а возможность.
Q: Какова ваша история работы с OpenStack? Почему вы заинтересованы в участии в проекте?
A: Я был техническим руководителем проекта Ubuntu Server в Canonical и работал над продуктом Ubuntu Enterprise Cloud. При создании OpenStack я вместе с несколькими коллегами из Rackspace помог организовать проект и выполнял функции управления релизами.
Я особо заинтересован в продвижении модели разработки по принципу “открытых инноваций”: создание ровной технической рабочей среды, которая позволяет разработчикам всей отрасли совместно работать над проектированием и разработкой OpenStack. Моя цель в проекте – убедиться в том, что мы придерживаемся этой модели, способствовать её поддержке и развитию и доказывать её успешность.
Q: Как компании принимают модель разработки по принципу “открытых инноваций”?
A: При работе по принципу открытых инноваций компании нанимают разработчиков для работы над проектом, но не контролируют сам проект. Они направляют приоритеты и интересы разработчиков внутри проекта, неявно, как посредники. Но, в общем, все участники проекта и лидеры среди них сами контролируют процесс. Компании вынуждены принять ситуацию, когда они должны отказаться от контроля в пользу влияния.
Q: Многие компании используют OpenStack, но не обмениваются опытом. Нужно ли это менять? Если да, то как? Или это обычная практика в проекте с открытым кодом?
A: Лицензия Apache позволяет компаниям взять код и не вносить вклад, поэтому это определенно обычная практика. Тем не менее, это не самая хорошая идея. Не вкладываясь в проект, вы значительно снижаете свое влияние на техническую сторону. Вы также сталкиваетесь с риском того, что новый код и дополнительные функции нарушают ваш рецепт работы кода. В конце концов, это не стоит того.
Q: Кто определяет принцип построения OpenStack – как принимаются решения?
A: Наш процесс разработки функций чрезвычайно открыт. Любой может предложить изменение, которое отправляется на просмотр нашими основными сотрудниками, проверяющими код. Учитывая сказанное (особенно для разрушающих функций), вы повышаете свои шансы на успешную проверку, если вы присоединились к рассылке по проектированию и разработке и участвуете в наших семинарах по разработке. Таким образом, сообщество может одобрить функцию перед тем, как на неё потрачено слишком много усилий. Процесс принятия решений – это достигаемый с минимальными усилиями компромисс между разработчиками в проекте. Для каждого проекта у нас есть избранный технический руководитель проекта, который может принять окончательное решение, но это требуется в очень редких случаях.
Q: Какова ваша ответственность в роли председателя технического комитета и менеджера по релизам?
A: Технический комитет – это финальное выражение технической меритократии в OpenStack. Члены комитета избираются участниками различных проектов. Его роль – рассматривать новые проекты, которые предлагаются для разработки в OpenStack, и решать потенциальные межпроектные проблемы. Будучи председателем комитета, я несу ответственность за отслеживание вопросов, выносящихся на рассмотрение комитетом, за запуск встреч по IRC и распространение результата этих встреч остальному сообществу.
Управление релизами имеет два аспекта. Первый из них (очевидно) – скоординировать выпуски различных проектов OpenStack, но с имеющимися у нас средствами автоматизации, это очень просто. Большинство работы по управлению релизами составляет управление шестимесячными циклами выпуска релизов, отслеживание того, что делается, и попытка предотвратить межпроектные помехи.
Q: Часто люди, заинтересованные в OpenStack, комментируют использование IRC. “Почему вы используете IRC? Это же давно устарело. Почему бы вам не использовать Twitter как все остальные?”
A: Хм. Не все хотят быть привязанными к проприетарной платформе обмена сообщениями! Я использую IRC последние 20 лет и считаю, что это идеальное средство для быстрых онлайн-дискуссий и организации встреч. У нас есть каналы, посвященные отдельным темам, и каналы отдельных команд. Это публичное пространство для общения, оно работает круглосуточно. Мы ведем журнал действий, то есть данные не пропадают. Мы также можем использовать прокси для подключения. Это очень широко распространено среди разработчиков, которые участвуют в наших проектах с открытым кодом, а большинство из нас используют их и за пределами OpenStack.
Q: Вы упомянули шестимесячные циклы выпусков. В чем их ценность?
A: Наиболее очевидная ценность циклов выпуска – это способствование выпуску релиза. Это помогает нам переместить фокус с разработки функций на багфикс критических ошибок к релизу, что повышает качество релиза. Для меня же наибольшая ценность циклов выпуска – это создание ритма усилий, определенного пульса, который очень важен для нашего виртуального и глобального сообщества в плане объединения в работе над одним и тем же проектом.
Q: Можете ли вы описать цикл выпуска OpenStack, от мозговых штурмов до реализации и интеграции?
A: Мы начинаем с Семинара по разработке, на котором разработчики, которые хотят работать над определенным проектом в течение следующего цикла, представляют свои идеи и обсуждают их с остальными разработчиками. Затем начинается реализация, которая искусственно разделяется на три кратких “этапа” для разбиения работы над проектом.
После третьего этапа разработки мы переключаемся на режим замораживания функций, при котором фокус смещается на исправление списка критических ошибок перед релизом. После того, как все критические ошибки исправлены, мы создаем релиз-кандидат. Если в нем не найдены критические для релиза ошибки (в этом случае мы можем исправить их и пересобрать новый релиз-кандидат), все кандидаты собираются в момент выпуска релиза для создания финального интегрированного релиза проектов OpenStack.
Q: Что определяет частоту выпусков OpenStack?
A: Мы пытаемся иметь всегда доступную к запуску основную ветку. “Релизы” на самом деле – просто точки во времени, теги в репозитории, которые мы помечаем как особые случаи. Наш цикл выпусков предназначен для снижения риска того, что критическая регрессия проникнет в наши ”релизы”, поэтому “релизы” несут меньше риска, чем случайная основная фиксация кода. Интересно то, что следует за этим: мы поддерживаем стабильные ветки, где мы применяем патчи для критических багфиксов и исправлений уязвимости, и эти стабильные ветки создаются именно из точек релизов.
Имеющаяся в данный момент частота выпуска релизов OpenStack – это компромисс между нашим желанием ускорить итерации, возможностью проводить Семинары разработчиков, необходимостью обновления документации после заморозки функций, частоты заморозки функций и наличием ресурсов для поддержки стабильных веток.
Q: Каковы преимущества и недостатки трехмесячного цикла выпуска?
A: Вы можете помнить, что в начале разработки OpenStack у нас был трехмесячный цикл разработки. Сейчас обычно проходит 4 недели с момента остановки добавления функций до получения работающего релиза-кандидата. При шестимесячном цикле выпуска возможно заморозить функции на месяц. В трехмесячном цикле выпуска этот период меньше. Выпуск каждые три месяца означает поддержание в два раза меньшего числа стабильных веток. Таким образом, если больше людей исправляет критические ошибки в оставшийся период цикла (не в период заморозки функций) и больше людей помогает поддерживать стабильные ветки и обновления безопасности, мы определенно можем перейти к трехмесячному циклу. Мне нравится проводить Семинар разработчиков в начале каждого цикла (Я думаю, это помогает нам достигать лучших результатов), поэтому, я полагаю, нам придется убедить Фонд оплачивать в два раза больше событий для разработчиков!
Q: Как разработчики могут принять участие, если они вынуждены пропустить семинар или не могут позволить себе поездку на Семинар разработчиков?
A: Участие в Семинаре разработчиков – ни в коем случае не необходимое условие для добавления кода в OpenStack. Обсуждение можно вести в списках рассылки или в системе проверки кода. Семинар разработчиков – это удобный способ быстрее пройти стадию мозгового штурма и стадии внедрения, получая на ранней стадии отзывы в живых личных обсуждениях.
Q: Не задумывается ли сообщество OpenStack о том, чтобы последовать по пути сообщества Ubuntu с семинаром разработчиком “только онлайн”? Сработает ли это для OpenStack?
A: Семинары разработчиков Ubuntu превратились в основе своей в упражнения по сбору отзывов, где основные разработчики представляют план своей работы на следующие несколько месяцев. Для этих целей виртуальная среда идеально подходит и экономит много денег. Семинары разработчиков OpenStack используются для другого: мотивация глобального и виртуального сообщества разработчиков на следующие шесть месяцев, мозговой штурм по идеям разработки или снижение дублирования усилий за счет общения с различными группами разработчиков. Но самая важная причина для того, чтобы оставить личное общение участников, это сохранение здравого смысла в сообществе. Личные встречи необходимы для того, чтобы разрешить любые конфликты, которые накапливались за 6 месяцев виртуального общения.
Q: Недавно мы взяли интервью у Монти Тейлора, технического руководителя проекта для непрерывной интеграции. Чем по вашему мнению непрерывная интеграция так важна для OpenStack?
A: Непрерывная интеграция позволяет нам доверять тому, что содержимое основной ветки работает и не содержит регрессии. OpenStack — сложное устройство и можно случайно его нарушить. Раньше я развертывал релиз локально и периодически запускал несколько ручных тестов, чтобы убедиться, что базовая функциональность не нарушена.
В сегодняшней инфраструктуре запускаются в тысячи раз больше тестов, чем я запускал ранее, и так для каждого предлагаемого изменения. Непрерывная интеграция позволяет мне спать спокойно. Без нее мы не были бы там, где мы сейчас.
Q: Есть ли области процесса разработки, которые ещё не автоматизированы, но будут автоматизированы в будущем?
A: Нет, все аспекты автоматизированы, хотя есть простор для улучшения. Некоторые проекты могли бы использовать больше тестов интеграции; ваша непрерывная интеграция хороша настолько, насколько хороши ваши тесты.
Q: Что разработчики, которые хотят участвовать в написании кода для OpenStack, должны привнести в проект?
A: Чувство юмора. Разработчики OpenStack – это сообщество приятных людей и хотелось бы, чтобы так было всегда!
Q: Какой совет вы бы дали новичкам — тем разработчикам, которые хотят внести вклад, и компаниям, которые хотят построить бизнес вокруг OpenStack?
A: Проект OpenStack – это то, что мы из него делаем. Присоединяйтесь, не пожалеете!
Q: Благодарим вас, Тьерри!
A: Спасибо!
Автор: Mirantis_OpenStack
