Несколько лет назад вOzonмежду двумя релизами приложения на одной платформе могло пройти три месяца.Мы планировали, что хотим выпуститься с определенной большой фичей и пока еёне сделаем не релизим.
С чем мы столкнулись, пока выпускали релизы по этой схеме:
-
Сложно спрогнозировать, когда выйдетфича.Ок,мы как-топрикидывалисроки, ночембольшебыл разрабатываемый функционал, тем сложнееточно оценить срок.Трекатьпрогресс фичитоже не очень удобно, потому что оно там делается,и промежуточныебилдыс чем-то готовым для посмотретьсложнособирать.
-
Долгоправитьбаги.Вкоде они могутбыть исправленыбыстро. А вотдо пользователейфиксдоходит уже вместе с той самой глобальной фичей.
-
Больно отключать легаси.Надо дождаться, когдаколичество пользователей нановых версиях будет уже достаточно большим.При редких обновлениях ждать этого иногда приходится годами.
-
Долго релизить мелкие фичи. Какие-то улучшения могут занимать немного времени на разработку, но быть важными для пользователей и бизнеса. Точно так же, какисправления багов в пункте выше, для релиза они будут ждать того монстра, которого мы пилимтримесяца.
-
Невыносимо долго проводить регрессионное тестирование. Всё,что было переделаноза несколько месяцев,мы будем проверять, чинить, перепроверять, чинить, перепроверятьНу, вы поняли
-
Многохотфиксов. Чем больше число и объем изменений, тем сложнеебудет найти все баги перед релизом. Вот и появляютсяхотфиксы. Ещёза такой долгий срок разработки может прилететь какая-то очень срочная фича, ждать нельзя надо срочно выпускать(например, поддержать разрешение на отслеживание или добавить что-то по срочному рекламному контракту).
Проблеммного,и они все значимые. Когда бизнеспришёл к нам и сказал, что надо релизить быстрее мы уже ожидали этого. Но не ожидали, что они скажут: Релизьте раз в неделю.
Мы в шоке, как это реализоватьнепонятно.
Тут у насслучиласьстадия отрицания:Мы не успеем всёпроверить, никаких фичей в релиз не попадет, Apple ревьюит о-го-госколько.Зачем, почему, может,не надо?.В ответ мы услышали: Релизы раз в неделю.
Сокращаем время выпуска релиза: первая попытка
Решили, что надодвигаться к целиитерационно.
Сначала научитьсявыпускать релизхотя быкопределённойдате. Первой попыткой был план успетьзарелизитьза месяц. Условно,мы решили 1 мая, что следующий релиз должен выйти 1 июня.
Ок, дата есть. Прикинули, что неделя уходит на регресс. На разработку остается три недели. Запланировали работына весь срок девелопмента.
Параллельно решили начать писатьавтотесты. Ну, как начать. У нас и до этого они были, но пользы не ощущалось. Поняли, что пора их встраивать в процессы.
Идёт первый месяц. Работаем. Пилим фичи, тестируем. Все заряжены.Но в итоге получили: тотобъём работ, который запланировали разработать за три недели, закончили под конецчетвёртой. Стали искать, где же выиграть время,нашли только один варианттестирование. Как могли, сократили регресс, но всёравно нашлинесколько критичных багов. В итогев зависимости от платформы с релизом опоздали на неделю-полторы.
Вторая попытка: нужно что-то менять
Да, мы решили, что нужны изменения. Но поменяли не процессы, а... сроки. Раз тяжело планировать на месяц давайте запланируем релизчерездве недели! Меньше успеем сделать фичей, быстрее проведем регрессионное тестирование - проще будет запланировать объем работ.
Тем временемтестировщикипродолжают писатьавтотесты
Пробуем всёравно каждый раз не успеваем.
Стали анализировать,из-за чегоне выходит уложиться в срок:
-
Неправильно оцениваем время на разработку.
-
Блочимсябекендом от этого тормозится и разработка, и тестирование.
-
Продактыпоздно вносятпоследниеправки в ТЗ.
-
Не учитываем время на починкубагов.
У нас был план:то, что не готово к началу тестирования в релиз неидёт. Но он не сработал.Приходилипродактыи говорили, что две недели ждать следующего релиза они не могут. Потомуходиливыше,и оттуданамговорили, что, да, надо доделать.
И тут пришлиQA.Сказали, что при двухнедельных релизахскоупнеособосократился.
Разработчиков много, они разделены по разномуфункционалуи задвенедели успеваютнакомититьпрактически во все компоненты. Стало понятно, что несмотря на то, что мыНИ РАЗУне успели в срок ни при месячном релизе, ни при двухнедельных пора двигаться дальше.
Недельные релизымыидём к вам!
Прежде всего надо было составить календарь наших действий на неделю. По разработке получилось так:
|
Понедельник |
Релизная ветка |
|
Вторник |
Фичи |
|
Среда |
Фичи |
|
Четверг |
Фичи |
|
Пятница |
Фиксы багов |
|
Фичиуходятвсвои фича-ветки. И когда она полностью сделана, проверена, принятапродактом, тогда уже попадает вdevelop. И вот на протяжении недели готовыефичисобираются вdev, в пятницу правим баги уже напрямуютам.А в понедельник всё, чтособралось отрезается в отдельнуюрелизнуюветку. В релиз уже ничего некоммитим, толькофиксимбаги, найденные нарелизномтестировании. Получается, что где-то в среду-четверг должен начаться процентныйроллаутприложения. |
Меняемся в тестировании
Чтобы всёэто поддержать со стороныQA, пришлось ротировать обязанности тестировщиков по неделям. Одну неделю тестер проверяетфичи, вторую занимается написанием кейсовиавтотестов,участвует врелизномтестировании.При этомрелизноетестирование получилось сократить где-то до дня на каждую платформу.
Помогли в этомнаконец-тодописанныеавтотесты, которыерегрессилибольшую часть приложения и сокращенныйскоуп - вручномрелизномтестировании участвовалитолько кейсысмоукаифункционал, который был задетвфичахэтого релиза.
Чтобы разработка не зависала на начальных этапах, мы выработали требования кфиче, которуюберём в работу у неёдолжныбыть в наличии
-
Дизайн;
-
Бекенд;
-
Контракт.
Если чего-то из этого нет смысла братьфичув разработку на мобильной платформе тоже нет.
Дальше встал вопрос о том, когда же можно включатьфичув релиз. Получились такие правила:
-
Бекендфичидолжен быть напродакшене.
-
К началурелизноготестирования нет критичныхбагов(ни на фронте, ни набекенде).
-
Дляфичиестьфичефлаг, которым в любой момент можно закрытьфункционал. По версии платформы, по версии приложения, по дате, на определенную группу пользователей как угодно.
Меняемся в разработке
В разработке тоже много чего поменяли.Прежде всего,появился максимальный приоритет напереоткрытыхтикетах. Потому что нам неважно,как много мы сделаем, если ничего из этого не попадет в релиз. Важно именно закрытьтикет, чтобы в итогефичапопала вdev.
Ещёмы постоянно автоматизируем процессы, чтобы разработчикам надо было меньше отвлекатьсяна какие-то рутинные вещи,и они могли сконцентрироваться на разработке.
Тикетавтоматом двигается по статусам. Запушилкоммит перешел вinprogress.Создалmergerequest перешел вcodereview.ПрошелreviewпопалвQA.
Втикетеавтоматически проставляется версия релиза, куда он попал и номербилда.
По каждой сборке запускаютсяUI-автотестыпозатронутомуфункционалу.Это тоже определяется самопо измененным файлам вmergerequest.В результате репорт попадаетвкомментарийтикета вJira.
Дажеmergerequestна влитие эпика вdevсоздаётсяпросто по принятию продактом фичивJira.Если нет конфликтов, то и вливается сам.Релиз сам закрывается, а новый самсоздаётся.
QA Notes
Ещёмы ввели требования к разработчикам писатьQANotes.Там указывается:
-
Что было сделано.
-
Что могло быть задето.
-
Приложены скриншоты или видео.
-
На какой среде удалось проверить.
-
Для багаещёпричина, из-за чегосломалось(в идеалетикет, которыйпривёл к такому поведению).
QANotesпозволили значительно ускоритьтестированиеиревьюкода. А ещёдали нам скрытый бонус:пропалиреопеныотQAиз-закрешейна старте.
Тестировщикампришлось тоже много чего поменять в своих процессах.Раньше любойчеловек из QAмог взятьтикетна тестирование любой части приложения.По задумке, этодавало большевовлечённостии свежихвзглядов. Нотормозило тестирование. Теперь тестировщикиразделены пофункционалу и чаще проверяют то, что за ними закреплено. Получается быстрее.
Автотестыраньше находят баги. Теперь не надо ждатьрелизноготестирования, чтобы увидеть проблемы после интеграции. Прогоныавтотестовпроисходят после каждоговливания эпика вdev,а такжекаждуюночь. Еслинадо, то можно запустить на эпик-веткедо вливания вdev. Раньше нашли баг раньше исправили.
Как и у разработчиков, уQAпоявился приоритет нафункционал, которыйпопадает в релиз. Именно этитикетыважнее всего проверять в первую очередь.
А еще добавиласьротируемаяроль QAза релиз.Этоттестировщикгде-то раз вдватримесяцаделаетповторяющиесявещи:
-
Составляет наборрелизныхтестов.
-
Распределяет нагрузку команды тестирования пофичам. Если видит, что у одних сейчас малотикетов, а другие не успевают может перекинуть кого-то в помощь.
-
Напоминаеттестировщикампосмотретьотчёты поавтотестамнарелизномбилде.
-
Пушитпересборкурелиз-кандидатов, если что-то добавилось.
-
После релиза неделюмониторитпаденияи отвечает на запросы поддержки.
В автоматизацию тестирования мы добавили не только проверкифункционала, но и аналитику, отправляемую приложением.
Автоматизация помогает контролировать стабильность среды с помощью выполнения тестов после изменения кода приложения:
Мы также проверяем, что новыеавтотестыне ломают существующие:
Новая схема релиза мобильных приложений
У нас стало значительно меньшехотфиксов.Релизы теперь чаще впять-десять раз, но хотфиксим мы реже, чем раньше.Причины две.Во-первых,получается делать более стабильные релизы.Во-вторых, если это не что-то невероятно критичное, то фикс, скорее всего, сможет подождать неделю до следующего релиза.
Теперь мы спокойнее переносимфичи. Неприятно, когда не успели, но перенос выхода фичи на неделю воспринимается спокойнее, чем на более долгий срок.
Продактамстало проще проверять готовность. Раньше они приходили к концу разработки, которая длилась месяц-другой, а теперь каждую неделю видят, чтопроисходит(а хорошиепродактычаще :) ).
И главное. Мы теперьукладываемсяв сроки. Всегда. С первой попытки выпустить релиз за неделю мы успели это сделать. И с тех пор вот уже два года приложениеOzonобновляется раз в неделю, принося новыефичи, исправления ошибок.
Какиеестьсложности
В первую очередь этонепростойрефакторинг. Когдавмерживодинкоммит, вам надо перепроверить всёприложение.Сейчас мы прежде всеговливаемтакое по понедельникам-вторникам, чтобырефакторингмаксимально настоялся вdev, накрутилсяавтотестамии был потроган при тестированиифичей.
Ещё однасложностьпраздники,из-за которых рабочая неделя из пяти дней сокращается дочетырёх. Тут появляется больше риска,т.к.обычно мырелизимнатретий-четвёртыйдень после отрезаниярелизнойветкииостаётсяещёдень на мониторинг.Тогда какздесь обычно релиз происходит уже в последний рабочий день. Спасибо, фичефлагами процентной раскатке.
Что ещёможно улучшить
Прежде всего хочется научиться ещёраньше раскатывать билды на пользователей. Найти тестовыесегменты, на которые можно катить до началарелизноготестирования. Но это рискимиджевыхи денежныхпотерь.Такихсуперлояльных пользователейнам ещё только предстоитпоискать.Если вдруг вамможет быть этоинтересно пишите, добавим вас в сегмент бета-тестировщиков.
Ещёмы никогда не останавливаемся в автоматизации процессов. Постоянно находим возможность убрать ручную рутину. И покрываемавтотестамивсёбольшефункционала.
Для себя мы выработали такие шаги, на которые надо пойти, чтобы завести у себя релизы раз в неделю:
-
Строгие требования к готовностифичи.
-
Приоритет напереоткрытыхтикетах.
-
Весь функционалзакрытфичефлагами.
-
Строгое расписание релизов.
И напоследок хочется сказать,если вы захотите перейти у себя на недельные релизы, будьте готовы, что меняться придется везде: и в разработке, и в тестировании, и в продуктовом планировании.
