Непрерывные релизы или «долгострой»: как часто стоит выпускать обновления своего продукта28.05.2016 13:52

Генеральный директор облачного сервиса «МойСклад» Аскар Рахимбердиев

Как правильно выпускать новые функции

Есть всего два основных подхода к выпуску новых версий продукта: можно накапливать массу новых функций и исправлений ошибок в больших релизах, которые выходят пару раз в год, а можно заливать обновления на продакшн как можно чаще — несколько раз в неделю или вообще в режиме реального времени.

Второй способ называется Continuous integration. В последнее время он становится всё более популярным. Его пиарит даже президент «Сбербанка» Герман Греф, который недавно стал увлеченным евангелистом agile-подходов. Тем не менее, у больших релизов есть свои преимущества, и многие вполне успешные и инновационные компании используют именно их.

Напомню, как выглядит процесс разработки. В обоих случаях он состоит из неделимых единиц, которые обычно называют тикетами или историями. Тикетом может быть новая функциональность или багфикс. В большом релизе целиком разрабатываются десятки и сотни тикетов, после чего проводится полное (регрессионное) тестирование всего продукта. Если тестирование завершено успешно, релиз выпускается на продакшн.

При непрерывной интеграции каждый тикет реализуется и тестируется в отдельной «песочнице» — бранче. После того, как пройдено ревью изменений в коде, а также ручные и автоматические тесты, тикет считается выполненным и заливается в мастер-ветку. Таким образом, в мастере всегда находится версия, пригодная для релиза. Ее можно выкладывать на продакшн каждую неделю, день или даже автоматически с каждым новым тикетом.

Мы в «МойСклад» перешли от больших релизов к непрерывному выпуску обновлений. Я попробую сравнить преимущества и недостатки обоих подходов, с которыми мы столкнулись на практике.

Большие релизы или долгострои

Преимущества

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

Управляемость. У большого релиза есть запланированная дата, к которой он должен быть выпущен. Отставание от нее показывает, насколько плохо обстоят дела. Возможно, бывает и опережение графика, но этого я еще не видел ни разу в жизни.

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

PR-эффект. Большое обновление — это событие и отличный инфоповод. Его можно красиво анонсировать, написать статьи, заказать обзоры, инициировать обсуждения в соцсетях. На базе новости «в 168 обновлении за год мы немного улучшили печать накладных» трудно запустить масштабную PR-кампанию.

Недостатки

Задержки. На практике мы постоянно сталкивались с тем, что реализация одной-двух сложных функций растягивалась на непредсказуемое время. Из-за этого приходилось задерживать весь релиз, в котором могли быть десятки готовых опций и багфиксов. Это оказывалось неприятно для исправлений ошибок. Иногда нам приходилось выпускать откровенно сырые релизы только для того, чтобы выложить давно ждущие багфиксы.

Неконтролируемая сложность. Одновременный выпуск нескольких новых функций приводил к тому, что сразу после релиза мы получали большое количество сообщений об ошибках. Работа над ними останавливала нормальный процесс разработки на одну-две недели. Еще хуже было то, что с первого взгляда часто было непонятно, какими изменениями вызвана конкретная проблема.

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

Непрерывные релизы

Преимущества

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

Оперативная реакция. Если мы выпускаем новую функцию и сразу понимаем, как ее нужно улучшить, изменения выходят на следующий день. Когда мы решаем изменить цвет кнопки, чтобы посмотреть, как это влияет на конверсию, новый вариант появляется сразу, а не в следующем релизе через два месяца. В целом этот процесс намного лучше подходит для модели lean startup и концепции постоянных экспериментов с изменением продукта.

Обновления четко делятся на платформенные и функциональные. Дело в том, что проблемы требуют различных исправлений. Например, при платформенных изменениях, когда меняется какая-то технология или внутренняя архитектура, нужно откатиться к предыдущей версии, чтобы потом спокойно разобраться. Баги в функциональном релизе проще исправлять быстро. При непрерывном выпуске обновлений у нас не возникает задачи сделать один релиз платформенным, а другой — с новыми функциями. Достаточно просто публиковать готовые тикеты по отдельности.

Недостатки

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

Кроме тестирования существуют еще накладные расходы на проведение самого релиза. Если размещение нового кода на продакшн-серверах можно и нужно автоматизировать, то всё равно остается задача мониторинга — всё ли в порядке у пользователей с новой сборкой. Эту проблему уже невозможно полностью переложить на скрипты.

Сползание графика. Теперь у релизов нет плановых дат, поскольку по факту нет и самих релизов. Мы остаемся с кучей тикетов, и у каждого из них есть примерная оценка времени реализации. Поскольку постоянное увеличение этого времени на день, два или неделю не затрагивает другие тикеты, его легко не заметить. Вместо одного большого проекта «выпустить релиз к 25 мая», мы получаем сотню мини- и микропроектов в виде отдельных тикетов. Управление ими требует бóльших усилий и бóльшего опыта проектного управления.

Выводы

После того, как мы перешли на непрерывные релизы, частота обновлений продакшн-системы увеличилась на порядок: с пяти до 54 раз за одинаковые промежутки в 2015 и 2016 году. Было бы логично предположить, что пользователи теперь меньше времени ждут исправлений. Действительно, медиана ожидания пользовательского тикета от момента создания службой поддержки до выхода фикса на продакшн уменьшилась с 17 до пяти дней (а среднее время — с 70 до 34). Думаю, это очень хороший результат.

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

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru