Что такое цикл релиза
Всë, что вам нужно знать об управлении релизами
В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.
Что это такое управление релизом?
Управление релизами охватывает все этапы выпуска программного обеспечения, от разработки и тестирования до развертывания. Управление релизом требуется каждый раз, когда запрашивается новый продукт, или даже изменения в продукт существующий. Есть пять основных шагов по управления релизом, которые мы делаем в этой ситуации:
Планирование релиза
Этап планирования в большинстве случаев интенсивен, так как именно на этом этапе весь наш релиз организуется от начала до конца. Надёжный план релиза помогает придерживаться верного пути и обеспечивать надлежащее соблюдение стандартов и требований.
При планировании релизов мы считаем, что разработанные несколькими командами приложения нуждаются в согласованном подходе, который должен быть выпущен заранее. Именно здесь в игру вступает концепция «трейн-релиза». Следуя подходу трейн-релиза, команды могут планировать изменения на основе релизов и отправлять их в Play Store.
Самым первым шагом, ещё до того, как мы начнём реализовывать трейн-релиз, является определение временных интервалов каждого этапа. В нашем случае этап разработки — это две недели. Затем нужно определить, сколько времени вы хотите потратить на интеграционное тестирование и этапы развёртывания. Ниже наш пример интервалов:
Следующий шаг на пути к релизам — создание рабочего процесса, к которому на протяжении всего релиза могут обращаться как наши команды, так и ключевые заинтересованные стороны.
Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент «Асана» для отображения этих деталей, перечисленных ниже:
Как только план утверждается и окончательно оформляется, начинается самое интересное!
Важные аспекты планирования релизов
Создание и использование трейн-релиза звучит здорово, но поддерживать процесс в рабочем состоянии во время планирования трейн-релиза может быть непростым. Вот некоторые детали этого процесса:
Построение релиза
После того как план выпуска готов, можно приступать к тестированию продукта для релиза. Это будет фактическое «тестирование уровня пользователя» продукта на основе изложенных в плане выпуска требований.
В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.
Автоматизируя переход ветки, мы проверяем все пороговые значения производительности, бенчмарк и автоматизации из предыдущих релизов в маркет устанавливаются на текущий как основание сравнения, а трейн-релиз блокируется от дальнейших изменений.
Как только код замораживается, начинается новый цикл разработки, и все участвующие команды начинают новый спринт и продолжают разработку. Самое замечательное в трейн-релизе: все знают о следующем, запланированном релизе, и это помогает людям соответствующим образом планировать свою работу.
Релиз веток и контроль версий
Разработка продукта обычно не останавливается, когда заканчивается разработка для релиза, поэтому первое, о чем мы думаем, это как заморозить тестируемую сборку и в то же время поработать над новыми возможностями для следующего релиза. Что случится, если в сборке релизов появится ошибка? Как исправить ошибку, если вы уже добавили кучу новых вещей до того, как эта ошибка нашлась?
Именно здесь на помощь приходит хитрая стратегия ветвления, в которой есть концепция разветвления. Как следует из названия, ветвление кода означает, что точно так же, как у веток дерева, код веток до определенной точки совпадает, а затем разбивается на две копии.
Каждая ветвь может развиваться независимо от другой. В этом случае одна копия — ветка релиза — остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть «замороженная» ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.
Пользовательское приемочное тестирование
Пользовательское приемочное тестирование является наиболее важным шагом для управления релизом из-за объема собранных данных и исправлений, необходимых для того, чтобы сделать сборку именно такой, какой она должна быть для официального запуска.
Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура — пользователь. Пользователи — это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:
Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!
Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.
Подготовка и релиз
Этот шаг заключается в том, чтобы внести последние штрихи в продукт, учитывая все, что было понято при UAT. Подготовка релиза также включает в себя заключительную проверку качества командой по контролю качества. В ходе проверки группа по контролю качества проводит окончательные проверки, чтобы убедиться, что сборка соответствует минимальным стандартам приемки и бизнес-требованиям из плана релиза.
После завершения ревью релиз-группа завершит релиз для начала развертывания. Перед тем, как сборка может быть развернуто в живой среде, она должно быть утверждена соответствующими ответственными командами, такими как команда дизайна. UAT гарантирует, что результат утверждается до передачи на следующий этап.
Развертывание релиза
Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:
В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.
Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.
Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.
Анализ после релиза
Работа по управлению релизом не заканчивается, когда публикуется код, продолжаясь до тех пор, пока вы не будете готовы выпустить релиз снова. Если вы хотите, чтобы ваше приложение было успешным, ему нужно хорошее ревью, вам также нужно следить за релизом в производственной среде, чтобы исправлять ошибки, внедрять функции, которые нужны людям, и решать проблемы пользователей. Для этого мы используем Firebase Crashlytics, где отслеживаем любые сбои, требующие немедленного исправления.
Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.
Подведем итоги
Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:
Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.
Управлять релизом просто: правила и этапы release management
Релиз является одним из самых важных и ожидаемых событий в жизненном цикле продукта. Приготовления к релизу могут занимать много усилий и времени, участия всей команды и заинтересованных сторон. Хорошо, если выпуск продукта или его версии проходит гладко и становится настоящим праздником. Но бывает иначе. Что из себя представляет эффективный релиз-менеджмент и как менеджерам продукта научиться его секретам?
Релиз связан с запуском нового продукта/сервиса/услуги или набором новых функций, изменений, которые становятся доступны клиентам или пользователям и обеспечивают новую продуктовую ценность.
Часто релиз состоит из ряда решений по устранению проблем и улучшений предоставляемых услуг, может включать изменения в ПО. На самом деле, это довольно значимое событие как для внутренних команд, так и для целевой аудитории.
Управление релизами помогает командам планировать свою работу и видеть конечный результат, а для клиентов это, своего рода, гарантия качества и получения новой ценности.
Хорошо подготовленный релиз — это не только предоставление доступа к новым техническим возможностям продукта. Это конечная дата, когда ваша команда может предоставить новый пользовательский опыт, поддержать и развить взаимодействие с ним.
Релизы должны включать все дополнительные задачи и активности, такие, например, как обновления на официальном сайте и в социальных сетях, обучение команды поддержки, обновление всех маркетинговых материалов и т. д.
Основная цель управления релизом — создавать, тестировать и доставлять новые возможности, которые будут удовлетворять все продуктовые требования и намеченные цели.
Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.
Что включает процесс управления релизом?
Понимание процесса управления выпуском продукта может отличаться у разработчиков и нетехнических специалистов. Важно учитывать все аспекты релиза и прислушиваться к мнению каждого члена команды.
Процесс управления релизом может включать следующие этапы:
В управлении релизом продукта могут участвовать практически все члены команды.
Product manager и Project Manager
Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.
Разбработчики
Команда разработки — это ключевые игроки в управлении релизом, поскольку они участвуют в большинстве процессов в жизненном цикле продукта. Они оценивают изначальные затраты и время, определяют основные требования, создают документацию и разрабатывают функциональность. Они принимают главные решения о том, что можно сделать и что не нужно, а также сколько времени это займет.
Маркетинг
Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.
Тестировщики
Тестировщики работают вместе с разработчиками. Их задача — тестировать результаты исследований и разработки, основываясь на установленных критериях. Продукт не придет к релизу, пока не будут учтены все замечания и критерии прохождения тестирований.
Служба поддержки
Support-команда или отдельный специалист поддержки первыми получают сообщения, елси что-то пошло не так. Они должны понимать и знать все о релизе и должны быть должным образом подготовлены на всех уровнях еще на стадии планирования.
Помимо этих основных ролей, к управлению релизом могут привлекаться и другие специалисты: отдела закупок, финансисты, sales, биллинг, system engineering и др.
Почему нужно внедрять процесса управления релизам?
Что такое Release Notes в процессе управления релизом?
Release Notes — это примечания к версии продукта, в которых описываются изменения между выпускаемой и предыдущей версиями этого продукта. Такой документ может составляться для пользователей и для внутренних команд: тестировщиков, маркетологов, службы поддержки.
Когда используются примечания к релизу?
Примечания к релизу распространяются вместе с продуктами. Иногда — когда продукты все еще находятся в разработке или тестировании. Документ может быть доставлен клиентам при выпуске обновления (для продуктов, которые уже были использованы клиентами).
Вы можете найти различные варианты написания Release Notes, поскольку для этого документа нет единого стандарта или формата. В разных компаниях менеджеры продуктов, тестировщики и разработчики, которые обычно ответственны за написание примечаний, обычно используют свои собственные шаблоны.
Вот как выглядит страница с примечаниями к релизу у Firefox:
Как писать примечания к релизу?
Содержание документа зависит от типа релиза. Вот пример основных пунктов:
Заключение
Управление релизом во многих компаниях становится отдельным самостоятельным процессом, который сообщает заказчику дату выпуска продукта и основные этапы его развития. Заказчик участвует в приоритизации и вовлечен в определение содержания релиза.
Процесс позволяет менеджерам продуктов и команде своевременно оценить загрузку и управлять объемом работ, доставлять изменения в срок. Управление релизами позволяет собирать собственную статистику, с которой удобнее в дальнейшем обосновывать запросы на дополнительные ресурсы.
Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)
Измеряем релизный цикл мобильных приложений
А давайте перенесем релиз на завтра? Мне тут один баг осталось пофиксить.
Если у вас только что случились вьетнамские флешбеки, значит эта статья точно для вас. Именно так начинается самый страшный кошмар тестировщика. И тогда происходит всё, что только может произойти: долгое review, баги в тестировании, а сами тесты падают. И пока ты фиксишь одно, тебе приходит уже новая фича, которую хочется выпустить в релиз. Потом — пятница, а мы ничего не зарелизили.
В этой статье я расскажу, как мы пришли к эффективному способу измерения качества релиз-трейна, какие совершали ошибки по пути и с какими сложностями столкнулись в процессе.
Как мы пришли к идее измерять качество релиза
Когда мы планировали второй квартал 2021 года, особое внимание решили уделить нашему релиз-трейну. С ним всё было вроде как нормально, но постоянно что-то да происходило: то мы забывали сделать какую-нибудь доработку, и нас заворачивали на review в App Store, то в релиз необходимо было добавить важную фичу. Релиз постоянно сдвигался, и это оставляло неприятное послевкусие. А что делать, когда существует недовольство, но вы не можете его сформулировать? Правильно! Нужно взять и померить, насколько всё плохо.
Зачем измерять релиз-трейн?
Ничего страшного, что мы отложили какую-нибудь штуку на денёк-другой. Никто не умер, всё хорошо, нет адской срочности. Так ведь?
Не совсем. Дело в том, что когда ваш релиз-трейн прибит гвоздями и релизы каждую неделю, мистер продакт точно знает, что в понедельник вечером отрежется релизная ветка, а в среду готовый релиз отправится в Google Play и App Store. В этом случае он не будет приходить с хотелками в формате: «А давайте бахнем релиз вот прямо сейчас, и чтоб моя фича в него обязательно попала. Сроки горят, голова чешется».
И вот вы сдвигаете дату релиза, чтобы попала эта фича, потом уже и другая туда целится, потом едет дата регресса и вот вы уже вынуждены сдвигать релиз на следующей неделе и никак не получается разорвать этот порочный круг.
Единственное, что вы можете сделать, чтобы этого не допустить — держать ваш релиз-трейн в тонусе и выпускать артефакты еженедельно в одно и то же время.
Что сложного в измерении?
Казалось бы, зачем все эти сложные измерения? Почему бы просто не взять каждый релиз и посмотреть, насколько позже он вышел? Всё не так просто. Мы же не хотим делать всё это руками, у нас лапки, мы хотим автоматизацию. И вот тут возникает множество корнер-кейсов.
Например, если мы затянули релиз настолько, что он вылетел уже на следующий понедельник, второй релиз на этой неделе делать мы уже не будем. А еще бывают всякие праздники, перевыпуски, нерабочие дни. Мы подумали и решили сделать самую простецкую метрику. Но для начала стоит погрузиться в нашу специфику.
О нашей специфике для контекста
Разработка у нас делится на большие задачи длиной в одну-две недели. Мы называем их «портфели». Портфели состоят из разработческих задач, в которых пишут цветные буковки и приносят продуктовую или техническую ценность. Портфель начинается с идеи, проходит через проработку продактами, разработку, релиз и имеет достаточно много статусов. Нам будут интересны следующие:
«Разработка» — именно в этом статусе идея обретает свой цифровой эквивалент в цветных буквах;
«Разработка: готово» — в этом статусе портфель пылится ожидая релиза;
«A/B эксперимент» — портфель вышел на пользователей, но так как в нем был эксперимент, его увидят в своем мобильном приложении только счастливчики;
«Обратная связь» — портфель ушел в прод и раскатан на всех.
Получается, чтобы понять, как долго портфель разлагался на плесень и липовый мед, нам необходимо измерить, сколько вообще он был в статусе «Разработка: готово».
Первая попытка измерений
Самая первая идея, что пришла нам в голову, была довольно банальной:
Смотрим дату, когда портфель перешел в статус «Разработка: готово»;
Если с этого момента прошло семь дней, а портфель все в том же статусе, помечаем портфель как “протухший”;
Для каждого дня считаем, сколько у нас протухших портфелей. Это будет показатель того, насколько у нас все плохо.
Данный показатель имеет смысл, потому что когда вас ждет один портфель – это плохо, но когда вас ждут десять портфелей — это уже залёт!
Вроде бы всё неплохо, но налицо неравенство и дискриминация по дате мерджа в develop. Portfolio Merge Days Matter! Те портфели, которые попали в develop раньше, и протухнут первыми, а те, что прямо перед релизом залетели в develop – значительно позже.
В жизни это выглядит следующим образом: в понедельник у нас портфель на флажке был смерджен в develop. Ребята старались, думали, как сделать, чтобы портфель попал куда надо, напряглись и подготовили. А срок “протухания” у него наступит только через неделю. И если вдруг даты регрессов поехали, этому портфелю уже задержали релиз. Не очень-то клево.
Мы подумали, что раз распределение портфелей у нас такое, то мы релизим их всегда в понедельник, и всё хорошо. Посмотрели, и оказалось, что наши портфели довольно равномерно размазаны по всем дням недели.
Разумеется, довольно много всего уходит в понедельник и вторник, но и в другие дни такие портфели тоже есть. Поэтому такой способ подсчета немножко сильно не подошел.
Вторая попытка измерений
Что нам важно? Нам важно смерджить портфель в develop, момент, когда он перешел в статус «Разработка: готово». Также нам важна дата следующего возможного релиза: подсчитать возможное окно. И уже оттуда мы будем отсчитывать дни, если он залежался. Получается, нужно взять дату, когда портфель попал в «Разработка: готово», и срок протухания отрезать. Промежуток, через который необходимо отрезать, будет свой для каждого портфеля.
Так и сделали. Получилась совсем другая метрика. Мы отталкивались от того, что следующая дата релиза будет в среду. В понедельник у нас ветка develop отрезается, но релиз при этом считается так, что чаще всего выходит примерно в среду. Получается уже более честная метрика.
На графике красным отображается первая итерация, а желтым — второй, более честный подход Метрика посчитана, и посчитана честно. С ней уже можно жить.
Мы так тоже подумали. Так начинался второй квартал. Когда пришло время на встрече по OKR check-in посмотреть, как обстоят дела, мы поняли, в чем ошибались. Ведь по этому графику абсолютно непонятно, хорошо наши дела или нет. Ведь метрика – это число от нуля до единицы. А у нас здесь пики! Ну вы поняли.
Как это вообще получилось, если все настолько очевидно? Дело в том, что метрики — это далеко не основная часть работы, и, получив какой-никакой индикатор для мониторинга, мы спешно побежали делать задачки.
Третья попытка измерений
Логика определения пиков протухания портфелей нам нравилась, поэтому проделанные вычисления хотелось переиспользовать. Во время брейншторма пришла следующая идея: «Не зря же мы учили матанализ. Давайте посчитаем интеграл от полученного графика».
Геометрическая интерпретация интеграла — площадь под графиком.
Выбираем день, для которого будем считать метрику
Выбираем длину окна, для котором будем считать интеграл. Пусть это будет 30 дней. Тогда мы будем учитывать кроме этого дня еще и 29 предыдущих
Считаем суммарный простой в портфеледнях: для каждого дня берем число протухших портфелей и добавляем его к общей сумме
Браво, мы получили общее число протухших портфелей дней за период
Теперь заставляем это окно скользить по нашему графику. Это можно сделать двумя способами: оставлять окно фиксированной длины и считать окно с начала квартала. Мы остановились на первом варианте, поскольку до второго на тот момент просто не додумались
И вот у нас получается уже новый график. На нем видно, что у нас были реальные проблемы с релизом, и нужно было над этим начать работать.
Остается вопрос: какое окно выбрать для расчета нашего интеграла? Сначала мы выбрали окно длиною 30 дней, так как на графике был огромный бугор из-за предыдущего квартала. Хотелось как можно быстрее про него забыть и смотреть на более свежие показатели. Кстати, если бы мы выбрали способ расчета с окном от начала квартала, то каждый квартал начинали бы с чистого листа.
Сначала мы смотрели только на 30-дневное окно. А сейчас наблюдаем окно в 90 дней. И как раз это дает нам представление, к какому результату мы придем к концу квартала.
Остался еще один шажок — нужно выбрать допустимое значение для этого графика, ведь задержка релиза раз в квартал на пару дней — это нормальное явление и не стоит чересчур закручивать гайки. Для 30-дневного интеграла мы выбрали порог в 20 протухших портфеледней, для 90-дневного — в 60.
Разбор инцидента с новым ростом значений на графике
Как видите, за квартал мы смогли прийти к тем показателям, которые взяли целевыми. Что мы делали, чтобы исправить ситуацию, достойно отдельной статьи. Однако в октябре метрика немного захворала, а к первому дню зимы уже снова стала выглядеть неприлично. Неужели все, что мы сделали, было напрасно?
Дело в том, что еще летом у нас активно релизилось только одно приложение соискателей, но в то же время активно переписывалось с нуля приложение для работодателей, а в начале сентября и середине октября был релиз на Android и iOS.
Главная проблема обнаружена, но что с этими приложениями не так? Мы нашли две причины:
Над приложением для соискателей работает 3 команды, а над работодательским — одна. Поэтому артефактов накапливалось достаточно мало и ребята не хотели релизить по одному портфелю
Приложение не было покрыто UI-тестами. Мы рассказывали, что покрываем UI-тестами только стабильный функционал, а после редизайна мы поменяли практически всё! Подробнее про автотесты и тестирование в hh смотрите в плейлисте на Youtube.
Стали думать, что делать. Две дополнительные команды и хорошее покрытие UI-тестами быстро не отрастишь.
Для начала мы решили исключить из запроса все портфели команды, которая занималась переписыванием приложения.
Как видите, фиолетовый график стал более пологим. Смотрим, в какие дни у нас квасились портфели. Здесь будет полезен график, полученный во второй итерации, который мы заботливо сохранили для таких целей.
На детализированном графике уже видно, что причиной служит пара пиков на графике релизов iOS-приложений, а затем в историю подключился и Android. Вот до чего доводит синхронизация платформ.
Нужно разобраться, что происходило с одной из платформ.
Ищем причину первого пика
Смотрим в App Store Connect: в этот период времени релизы были 11, 14 и 28 октября:
6.46 — Начало выпуска: 11.10.2021
6.47 — Начало выпуска: 14.10.2021
6.49 — Начало выпуска: 28.10.2021
Так, похоже релиз похитил злой Гринч задолго до Рождества, ищем в поиске в Slack строчку “6.48”. Понятно.
Смотрим баг, который аж отложил релиз, но это уже совсем другая история.
Ищем причину второго пика
Релизы iOS приложения были 28 октября, 16 и 22 ноября.
Смотрим на календарь, и получается, что релиза не было как раз в “нерабочую” неделю Шредингера. Если бы мы учли эти дни в предсказании даты предполагаемого релиза, то пика бы не было.
Вот мы и разобрали причины скачков метрик без мам, пап и поисков по Jira. Осталось понять, что делать со вторым приложением.
Несколько приложений в одной кодовой базе
В нашем случае всё решилось очень просто: мы договорились перейти на еженедельный релиз, так как в данной команде кроме сотрудников из hh мы подключили аутстафом ребят из SimbirSoft и эта команда поставляет достаточно много фичей, чтобы наполнить релиз. Кроме того, у нас в этой большой команде пропорция QA|Разработчики сдвинута в пользу QA и выглядит как 2:6 вместо обычных 1:4. Таким образом, команда успевает делать регресс и увеличивать покрытие UI-тестами.
Если вы не располагаете ресурсами и релизный цикл длиной больше недели можно рассмотреть следующий вариант:
Наш авторелиз записывает в базу данных дату релиза. Это позволит рассчитать прогноз для каждой следующей релизной даты. Кстати, если заинтересовал наш авторелиз, про него посмотреть «Охэхэнную историю».
Что можно улучшить и как жить дальше
Как следует из статьи, метрика считается довольно просто. При этом дни активной работы с релизом могут пересечься с какими-то из праздников, например, как у нас с “нерабочей” неделей при разборе полётов. Соответственно, релиз по плану должен быть не на этой неделе, а на следующей, а наша бездушная машина, увы, это не учитывает.
Ближе к новому году, мы дотюним расчет, чтобы не было ложно-положительных срабатываний.
Итоги
Во втором квартале, когда метрика была для нас целевой, мы достаточно хорошо над ней поработали и достигли поставленного порога в 60 протухших портфеледней. Каждое планирование мы смотрели на показатели и думали: «А что мы можем сделать?». Если ваш релиз-трейн оставляет у вас неоднозначные ощущения, советуем его померить. В настоящее время мы уже в фоновом режиме следим за данным показателем и стараемся не выбиваться из поставленных значений.
Как метрику стоит использовать площадь под графику, а для разбора инцидентов будет крайне полезен график с ежедневным числом протухших портфелей.
На этом всё. Пусть ваши метрики ползут в нужном направлении, а релиз-трейн летит вперед.