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

Как готовиться к релизу?

Выбрать ответственного человека

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

Настроить календарь

Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.

Сделать таблицу в вики

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

Release notes

Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.

Внутренний анонс

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

Во время релиза

Создать релизный бранч

Код, который подлежит выпуску не должен меняться, за исключением исправления критических багов. И в идеальном случае любой фикс должен пройти пул-реквест. Так же все тесты должны быть зеленые.

Отправить уведомление

Нужно уведомить всех по почте или в мессенджере о том, что создан релизный бранч и идет подготовка к релизу.

Сделать тэг

Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.

Сделать сам релиз

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

Релиз одной кнопкой

Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.

Если все пошло не так, как планировалось

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

После релиза

Мониторить

Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.

Сообщить об успехах и неудачах

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

Провести ретроспективу

Это, конечно же, частично зависит от методологии разработки, но если что-то в процессе релиза пошло не так — это стоит обсудить. Если что-то было хорошо, то это также стоит обсудить. В идеале на доске на каждый пункт неудачи должен быть пункт успеха либо благодарность коллеге. Это поможет не скатить ретроспективу в нытье и негатив.

Заказать пиццу и отпраздновать

Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.

Начать подготовку к следующему релизу

Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.

Как проводят релиз другие компании?

Spotify

Спотифай релизит часто, основываясь на практике Release train. Как намекает название этой практики, релиз очень похож на поезд: кто не успел закончить свою работу, ждет следующего релиза. Плюсы такого подхода в том, что не успевающая команда не задерживает доставку продукта и не пытается втолкнуть недоделанные таски. И как следствие, у девопсов ночами не разрываются телефоны, а дежурная команда на утро не появляется на работе с мешками под глазами. Безусловно такой подход не подойдет аутсорсинговой компании: клиент не станет платить за недоделанную работу. Скажу прямо: мне нравится культура компании, советую посмотреть видео (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) о том, как она работает.

Booking

Эти ребята тоже очень крутые. Релизы у них основаны на A/B тестах. Допустим, есть текущая стабильная версия — версия А, и есть версия, которую только что закончил разработчик, — версия B. Если в версии B KPI лучше, то стоит увеличить процент пользователей для этой версии. Если же версия B хуже, то тут есть два варианта: версия B просто не стабильна или просто фича никому не нужна. Такой подход подойдет компании, которая бережно относится к своему работающему продукту, но революции она скорее всего не сделает. Если вам интересно узнать больше про бережливое производство, прочтите книгу Lean Startup (http://theleanstartup.com/).