Авторы: Игорь Марнат, Илья Стечкин
С 7 по 9 марта проходил Global OpenStack Bug Smash Mitaka. Mirantis принимал две площадки этого ивента: одна из них — в московском офисе компании. Россия впервые присоединилась к проведению BugSmash. И мы рады, что это произошло при нашем непосредственном участии.
Почему для комьюнити так важно, чтобы крупные игроки рынка, такие, как Intel, Rackspace, Mirantis, IBM, HPE, Huawei, CESI или SUSE, поддерживали работы по проверке и повышению качества кода? Какое место занимает этот событие в процессе создания платформы OpenStack?
Разработка функционала и фикс багов — два разных, но сильно связанных между собой процесса. Такое утверждение справедливо для любого программного продукта. Но в случае с открытым кодом есть нюанс: все, кто может создавать что-то новое, предпочтут заниматься именно этим, а не тратить время на просмотр чужого кода и внесение исправлений в него.
Даже в литературе, музыке или изобразительном искусстве есть те, кто создает произведения и те, кто анализирует их (критики всех мастей). Но если продуктивность писателя, композитора или художника не всегда выигрывает от пристального внимания критиков, то программный продукт всегда улучшается, становится чище и стабильнее, если на него смотрят свежим взглядом. Суть процесса разработки OpenStack в том, что он ведется открыто и каждое изменение всегда проверяют несколько человек.
Кроме того, в каждом релиз-цикле есть технический долг, который тормозит разработку нового функционала. Простой пример из внутренней кухни Mirantis: мастер-нода до релиза MOS 7.0 базировалась на устаревшей версии CentOS. Это замедляло процесс совершенствования продукта, не давало возможность имплементировать некоторые интересные фичи. Но в релизе MOS 8.0 мы доблестно этот технический долг выплатили, обновив мастер-ноду, позволив разработчикам использовать последние версии библиотек и пользователям вовремя получать обновления.
Однако, опыт показывает, что технический долг накапливается от релиза к релизу. И разработчики вынуждены делить свое время между созданием нового функционала и частичной ликвидацией долга. Так что, на “ловлю блох” время выделяется по остаточному принципу, так как давление со стороны продакт-менеджмента всегда направлено на разработку новых прикольных фич, которые можно продать, а не на исправление старых скучных багов, которые уже проданы.
В первую очередь устраняются критические ошибки (critical bugs). Это такие баги, при наличии которых фича не работает совсем. Дальше в работу поступают существенные ошибки (high bugs). При наличии таких багов фича работает, но не совсем так, как должна, а “с костылями” — со значительными доработками, компенсирующими наличие данной ошибки. Например, пользователю приходится рестартовать сервис, чтобы он продолжил работать корректно.
Баги уровня ниже “high” редко достигают внимания разработчиков, которые всегда находятся в жестких рамках расписания нового релиза, параллельно исправляя high & critical баги в предыдущих релизах. Поэтому баги более низкого приоритета могут висеть годами и переноситься из релиза в релиз. Они и висят. И переносятся из релиза в релиз. Проблема в том, что баги средней значимости (medium bugs) связаны с юзабилити, их часто заводят сами пользователи. Можно сказать, что их наличие портит впечатление от работы с проектами экосистемы (customer experience). Вот пример такого бага с ЧЕТЫРЕХЛЕТНЕЙ историей ( dhcp server defaults to gateway for filtering when unset). Вот более “молодой” баг — ему всего 2 года ( Enable metadata when create server groups). Оба бага имеют отношение к проекту Nova (официальное название проекта — OpenStack Compute). Всего в этом крайне важном для экосистемы проекте 483 бага разной “степени тяжести” (на момент написания статьи)! Так что вся надежда только на то, что один раз в релизный цикл разработчики отложат свои дела ради охоты на баги. И код станет чище.
Определим место Bug Smash в процессе контроля качества (QA). Существует мнение, что QA — это исключительно тестирование. Однако опытные разработчики (в том числе те, кто работает в компаниях, создающих проприетарные продукты, таких как Cisco) знают, что тестирование — это только часть QA. Большое количество багов может быть выявлено на этапе проверки качества кода другими разработчиками (code review). Обычно code review предшествует тестированию. А значит — цена ошибки, найденной в процессе review, ниже.
Широко известно, что чем раньше найдена проблема — тем дешевле обойдется процесс ее устранения. Например, согласно данным, приведенным в книге Макконнелла «Совершенный Код», исправление ошибки на этапе тестирования обойдется в десять раз дороже, чем на этапе разработки кода. Тестирование — процедура трудозатратная, а потому — недешевая. Требуется поднять лабу с соответствующими характеристиками, составить сценарий тестирования, провести тестирование и устранить неполадки, выявленные в процессе тестирования.
Самая дорогая ошибка — та, которую нашел пользователь. Та, которую упустили из виду ревьюеры и не отловили тестировщики. В этом случае цепочка исправления начинается с саппорта. Специалисты службы поддержки получают обращение клиента, диагностируют проблему, для чего, скорее всего, повторяют процедуру тестирования: то есть поднимают лабу и — далее по тексту (см. выше).
Наиболее продвинутые пользователи, имеющие в команде людей из сообщества OpenStack, сами обнаруживают баги и информируют о них сообщество. Однако, поскольку эти баги не относятся к категории critical или high, то разработчики редко имеют возможность поработать с ними. Круг замкнулся.
Таким образом, трудно переоценить важность OpenStack Bug Smash, марафона, который проходит в рамках каждого релиз-цикла OpenStack, и позволяет разработчикам выделить время на работу с теми багами, которые обычно остаются за пределами их поля зрения.
Выигрывают от этого все: и пользователи, получающие, наконец, решение своих проблем. И компании-контрибуторы, экономящие деньги за счет раннего выявления и исправления ошибок в коде. И вся экосистема, поскольку повышается уровень удовлетворенности клиентов, а значит — появляются новые возможности для роста бизнесов, построенных на создании и внедрении решений на базе OpenStack.
Ну и еще существенный результат мероприятия — это привлечение новых контрибуторов и вообще распространение знаний об OpenStack в мире. В Нью-Йорке на аналогичном событии весь первый день потратили на подготовку новичков, которые пришли учиться работать с OpenStack, и только на второй день уже начали фиксить баги. В Москве мы тоже отвели день на работу с теми, кто только начинает свое погружение в OpenStack. Удачи и стабильного кода!
С 7 по 9 марта проходил Global OpenStack Bug Smash Mitaka. Mirantis принимал две площадки этого ивента: одна из них — в московском офисе компании. Россия впервые присоединилась к проведению BugSmash. И мы рады, что это произошло при нашем непосредственном участии.
Почему для комьюнити так важно, чтобы крупные игроки рынка, такие, как Intel, Rackspace, Mirantis, IBM, HPE, Huawei, CESI или SUSE, поддерживали работы по проверке и повышению качества кода? Какое место занимает этот событие в процессе создания платформы OpenStack?
Разработка функционала и фикс багов — два разных, но сильно связанных между собой процесса. Такое утверждение справедливо для любого программного продукта. Но в случае с открытым кодом есть нюанс: все, кто может создавать что-то новое, предпочтут заниматься именно этим, а не тратить время на просмотр чужого кода и внесение исправлений в него.
Даже в литературе, музыке или изобразительном искусстве есть те, кто создает произведения и те, кто анализирует их (критики всех мастей). Но если продуктивность писателя, композитора или художника не всегда выигрывает от пристального внимания критиков, то программный продукт всегда улучшается, становится чище и стабильнее, если на него смотрят свежим взглядом. Суть процесса разработки OpenStack в том, что он ведется открыто и каждое изменение всегда проверяют несколько человек.
Кроме того, в каждом релиз-цикле есть технический долг, который тормозит разработку нового функционала. Простой пример из внутренней кухни Mirantis: мастер-нода до релиза MOS 7.0 базировалась на устаревшей версии CentOS. Это замедляло процесс совершенствования продукта, не давало возможность имплементировать некоторые интересные фичи. Но в релизе MOS 8.0 мы доблестно этот технический долг выплатили, обновив мастер-ноду, позволив разработчикам использовать последние версии библиотек и пользователям вовремя получать обновления.
Однако, опыт показывает, что технический долг накапливается от релиза к релизу. И разработчики вынуждены делить свое время между созданием нового функционала и частичной ликвидацией долга. Так что, на “ловлю блох” время выделяется по остаточному принципу, так как давление со стороны продакт-менеджмента всегда направлено на разработку новых прикольных фич, которые можно продать, а не на исправление старых скучных багов, которые уже проданы.
В первую очередь устраняются критические ошибки (critical bugs). Это такие баги, при наличии которых фича не работает совсем. Дальше в работу поступают существенные ошибки (high bugs). При наличии таких багов фича работает, но не совсем так, как должна, а “с костылями” — со значительными доработками, компенсирующими наличие данной ошибки. Например, пользователю приходится рестартовать сервис, чтобы он продолжил работать корректно.
Баги уровня ниже “high” редко достигают внимания разработчиков, которые всегда находятся в жестких рамках расписания нового релиза, параллельно исправляя high & critical баги в предыдущих релизах. Поэтому баги более низкого приоритета могут висеть годами и переноситься из релиза в релиз. Они и висят. И переносятся из релиза в релиз. Проблема в том, что баги средней значимости (medium bugs) связаны с юзабилити, их часто заводят сами пользователи. Можно сказать, что их наличие портит впечатление от работы с проектами экосистемы (customer experience). Вот пример такого бага с ЧЕТЫРЕХЛЕТНЕЙ историей ( dhcp server defaults to gateway for filtering when unset). Вот более “молодой” баг — ему всего 2 года ( Enable metadata when create server groups). Оба бага имеют отношение к проекту Nova (официальное название проекта — OpenStack Compute). Всего в этом крайне важном для экосистемы проекте 483 бага разной “степени тяжести” (на момент написания статьи)! Так что вся надежда только на то, что один раз в релизный цикл разработчики отложат свои дела ради охоты на баги. И код станет чище.
Определим место Bug Smash в процессе контроля качества (QA). Существует мнение, что QA — это исключительно тестирование. Однако опытные разработчики (в том числе те, кто работает в компаниях, создающих проприетарные продукты, таких как Cisco) знают, что тестирование — это только часть QA. Большое количество багов может быть выявлено на этапе проверки качества кода другими разработчиками (code review). Обычно code review предшествует тестированию. А значит — цена ошибки, найденной в процессе review, ниже.
Широко известно, что чем раньше найдена проблема — тем дешевле обойдется процесс ее устранения. Например, согласно данным, приведенным в книге Макконнелла «Совершенный Код», исправление ошибки на этапе тестирования обойдется в десять раз дороже, чем на этапе разработки кода. Тестирование — процедура трудозатратная, а потому — недешевая. Требуется поднять лабу с соответствующими характеристиками, составить сценарий тестирования, провести тестирование и устранить неполадки, выявленные в процессе тестирования.
Самая дорогая ошибка — та, которую нашел пользователь. Та, которую упустили из виду ревьюеры и не отловили тестировщики. В этом случае цепочка исправления начинается с саппорта. Специалисты службы поддержки получают обращение клиента, диагностируют проблему, для чего, скорее всего, повторяют процедуру тестирования: то есть поднимают лабу и — далее по тексту (см. выше).
Наиболее продвинутые пользователи, имеющие в команде людей из сообщества OpenStack, сами обнаруживают баги и информируют о них сообщество. Однако, поскольку эти баги не относятся к категории critical или high, то разработчики редко имеют возможность поработать с ними. Круг замкнулся.
Таким образом, трудно переоценить важность OpenStack Bug Smash, марафона, который проходит в рамках каждого релиз-цикла OpenStack, и позволяет разработчикам выделить время на работу с теми багами, которые обычно остаются за пределами их поля зрения.
Выигрывают от этого все: и пользователи, получающие, наконец, решение своих проблем. И компании-контрибуторы, экономящие деньги за счет раннего выявления и исправления ошибок в коде. И вся экосистема, поскольку повышается уровень удовлетворенности клиентов, а значит — появляются новые возможности для роста бизнесов, построенных на создании и внедрении решений на базе OpenStack.
Ну и еще существенный результат мероприятия — это привлечение новых контрибуторов и вообще распространение знаний об OpenStack в мире. В Нью-Йорке на аналогичном событии весь первый день потратили на подготовку новичков, которые пришли учиться работать с OpenStack, и только на второй день уже начали фиксить баги. В Москве мы тоже отвели день на работу с теми, кто только начинает свое погружение в OpenStack. Удачи и стабильного кода!