Руководитель направления функционального тестирования одного из наших банковских проектов, рассказала нам про процесс управления релизами, как на их проекте менялась технология поставки задач на продуктив и как все работает сейчас.
Как было?
Релизный процесс у нашего Заказчика, работающего в банковском секторе, представляет собой масштабную работу по обновлению и продуктовых систем, и приложений для работы сотрудников банка, и клиентских приложений. Разные части функционала разрабатываются в разных командах, с использованием различных стеков технологий. А над достижением конечной цели трудятся сотни сотрудников.
Во всей этой огромной машине время от времени случаются сбои. Например, к моменту релиза обнаруживается, что какие-то доработки никак не получается стабилизировать. Или прибегает менеджер с требованием довключить “сырой” функционал.
В чем проблема?
Все это растягивало релизный цикл и, в итоге, привело к следующим проблемам:
· из-за ожидания доделок одних задач, задерживалась поставка на продуктив других. Как следствие: заказчик не получал прибыль, которую рассчитывал получить за счет продажи новых продуктов и оптимизации процессов;
· овертаймы команды тестирования становились нормой жизни;
· несчастные пользователи: с каждым релизом мы поставляем на продуктив не только новый функционал, но и фиксы существующих в системе дефектов. Чем дольше мы задерживаем исправление ошибок, тем дольше клиентам банка, операторам в банковских офисах и контакт-центре приходится использовать приложения с этими ошибками и искать обходные пути для выполнения задач.
Было очевидно, что наш релизный процесс нуждается в реорганизации.
Что решили делать?
Итак, мы решили внедрить у себя модель непрерывных релизов, чтобы сократить срок доставки функционала на продуктив. За основу была взята методология SAFe. Такой процесс релиза в банке называется train (от англ. “поезд”). Что это значит?
Наш релиз как поезд, двигается по строгому расписанию. В конце года релиз-менеджеры составляют план релизов на весь следующий год, где фиксируют даты релизов с частотой каждые две недели. В момент составления плана мы не знаем какие доработки будут реализованы и не подстраиваем график под их выпуск. Важный момент такого планирования заключается в том, что даты релизов впоследствии не меняются. Если релиз запланирован на определенную дату, то именно в эту дату он и будет поставлен.
Как поезд, идущий по расписанию, ни минутой раньше ни минутой позже.
Этот план помогает определять сроки по исправлению ошибок программного обеспечения и сообщать их пользователям. А также помогает продуктовым командам планировать даты выпуска своих доработок на продуктив.
Чтобы быть включенной в релиз, задача должна подходить под четкие критерии. К моменту сбора дистрибутива по задаче должно быть завершено тестирование и оформлены протоколы тестирования, исправлены все дефекты, с которыми нельзя выходить на прод, весь код передан сопровождению для сборки, после сборки проведено приемочное тестирование на общей среде регресса, информация по задаче передана команде регресса для корректировки регрессионных тестов и покрытия автотестами.
Задачи, не подходящие под эти условия, не допускаются до посадки на поезд.
Если в процессе приемочного или регрессионного тестирования обнаруживаются критичные дефекты, которые не могут быть решены к зафиксированной дате релиза, то такую задачу мы вынуждены “вырезать” из релиза или, иными словами, высадить пассажира из поезда, а не ждать фиксов дефектов и переносить дату релиза.
Чтобы не доводить ситуацию до такого, команды, реализующие фичи, также работают по принципам SAFe и в разработке следуют следующим правилам:
декомпозиция задач. Разбиваем задачу на мелкие кусочки, которыми проще управлять и можно поставлять на прод по частям;
2. в качестве подстраховки используем feature toggle. т.е. переключатель, на случай, если что-то пошло не так, мы можем “выключить” наши доработки;
3. после установки задачи на тестовую среду релиза проводим happy path.
Бывают ситуации, когда процесс разработки задачи завершен на день позже после фиксации скоупа релиза или даже на несколько часов. И как велик соблазн запрыгнуть в последний вагон уходящего поезда. Но нужно понимать, что включение такой задачи приводит к большим рискам. Поэтому такая задача не включается в текущий релиз и ждет следующий. Иными словами, если вы купили билет на поезд, но опоздали на него, поезд уезжает без вас, а вы остаетесь на перроне ждать следующий. Обидно? Очень.
Но в большинстве случаев, т.к. релизный цикл у нас короткий, то подождать 2 недели - не критично и даже более приемлемо, чем в спешке выпустить сырой функционал.
Конечно, в каждом правиле есть исключения. К сожалению, иногда возникают ситуации, когда на продуктиве “выстреливает” супер-критичная ошибка и ожидание следующего поезда сулит банку большими потерями. В таком случае мы либо включаем такой функционал в релиз, либо выпускаем внеплановый патч, на случай, если даже ожидание ближайшего релиза будет очень дорого нам стоить. Внеплановый патч устанавливается независимо от запланированного графика релизов и не влияет на текущий график, т.е. сдвигов не происходит, а запускается как бы дополнительный поезд только с этим исправлением. Но нужно отметить, что эта практика не есть норма и поступаем так только в критических ситуациях.
Что в итоге?
В рамках рабочего процесса нашего заказчика такой подход успешно функционирует уже несколько лет и показывает хороший результат. Мы выстроили процесс так, что график релизов соблюдается и процесс подготовки очередного релиза стал более контролируем, а также повысилось качество выпускаемого релиза.