Релизить продукт — это самая важная часть работы любой софтверной компании. Но если вы боитесь делать релиз, то возможно вы что-то делаете не так. Я расскажу как обычно организовываю релиз. Данная статья не претендует на исчерпывающее руководство поскольку в индустрии разработки программного обеспечения все индивидуально.
Можно дежурить по очереди, либо бросать игральные кости, либо тянуть спички —любой способ хорош. Важна ротация людей и обучение тех, кто не умеет делать релиз. Например, при броске костей можно ввести правила что тот, кто дежурил в прошлый раз, имеет право перебросить, а если дежурил два раза подряд, то автоматически не дежуришь. Дежурство не должно восприниматься как наказание или повинность, и обязательно должны быть люди, которые могут подстраховать.
Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.
Укажите таблице версию, дату и человека, ответственного за релиз. Это больше нужно для ведения исторических данных. Можно и нужно тут же отметить, был ли релиз успешный и что именно вошло в релиз.
Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.
Другим отделам важно знать когда произошел релиз, чтобы, например, сделать посты в соц. сетях о новой версии продукта (создать инфоповод), следить за KPI (возможен рост или падение метрик) и т.д.
Код, который подлежит выпуску не должен меняться, за исключением исправления критических багов. И в идеальном случае любой фикс должен пройти пул-реквест. Так же все тесты должны быть зеленые.
Нужно уведомить всех по почте или в мессенджере о том, что создан релизный бранч и идет подготовка к релизу.
Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.
В идеальном варианте у вас должны быть механизмы, которые контролируют релиз: например, сделать релиз только на 10% пользователей или только на не платящих. Это необходимо для того. чтобы уменьшить урон от ошибок, которые возникли в процессе разработки и не были найдены во время тестирования.
Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.
Конечно же в случае какой-либо ошибки нельзя друг друга обвинять, а нужно решить проблему вместе и придумать план по предотвращению подобных инцидентов в будущем.
Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.
Намного лучше если о проблеме узнают от разработчиков, а не от пользователей. И конечно же, если вы решили какие-то проблемы, то этим можно смело похвалиться.
Это, конечно же, частично зависит от методологии разработки, но если что-то в процессе релиза пошло не так — это стоит обсудить. Если что-то было хорошо, то это также стоит обсудить. В идеале на доске на каждый пункт неудачи должен быть пункт успеха либо благодарность коллеге. Это поможет не скатить ретроспективу в нытье и негатив.
Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.
Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.
Спотифай релизит часто, основываясь на практике Release train. Как намекает название этой практики, релиз очень похож на поезд: кто не успел закончить свою работу, ждет следующего релиза. Плюсы такого подхода в том, что не успевающая команда не задерживает доставку продукта и не пытается втолкнуть недоделанные таски. И как следствие, у девопсов ночами не разрываются телефоны, а дежурная команда на утро не появляется на работе с мешками под глазами. Безусловно такой подход не подойдет аутсорсинговой компании: клиент не станет платить за недоделанную работу. Скажу прямо: мне нравится культура компании, советую посмотреть видео (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) о том, как она работает.
Эти ребята тоже очень крутые. Релизы у них основаны на A/B тестах. Допустим, есть текущая стабильная версия — версия А, и есть версия, которую только что закончил разработчик, — версия B. Если в версии B KPI лучше, то стоит увеличить процент пользователей для этой версии. Если же версия B хуже, то тут есть два варианта: версия B просто не стабильна или просто фича никому не нужна. Такой подход подойдет компании, которая бережно относится к своему работающему продукту, но революции она скорее всего не сделает. Если вам интересно узнать больше про бережливое производство, прочтите книгу Lean Startup (http://theleanstartup.com/).
Как готовиться к релизу?
Выбрать ответственного человека
Можно дежурить по очереди, либо бросать игральные кости, либо тянуть спички —любой способ хорош. Важна ротация людей и обучение тех, кто не умеет делать релиз. Например, при броске костей можно ввести правила что тот, кто дежурил в прошлый раз, имеет право перебросить, а если дежурил два раза подряд, то автоматически не дежуришь. Дежурство не должно восприниматься как наказание или повинность, и обязательно должны быть люди, которые могут подстраховать.
Настроить календарь
Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.
Сделать таблицу в вики
Укажите таблице версию, дату и человека, ответственного за релиз. Это больше нужно для ведения исторических данных. Можно и нужно тут же отметить, был ли релиз успешный и что именно вошло в релиз.
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/).
