Как организовать релиз по

Как организовать релиз

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

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

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

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

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

Release notes

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

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

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

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

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

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

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

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

Сделать тэг

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

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

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

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

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

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

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

После релиза

Мониторить

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

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

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

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

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

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

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

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

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

Управлять релизом просто: правила и этапы release management

Релиз является одним из самых важных и ожидаемых событий в жизненном цикле продукта. Приготовления к релизу могут занимать много усилий и времени, участия всей команды и заинтересованных сторон. Хорошо, если выпуск продукта или его версии проходит гладко и становится настоящим праздником. Но бывает иначе. Что из себя представляет эффективный релиз-менеджмент и как менеджерам продукта научиться его секретам?

Релиз связан с запуском нового продукта/сервиса/услуги или набором новых функций, изменений, которые становятся доступны клиентам или пользователям и обеспечивают новую продуктовую ценность.

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

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

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

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

Основная цель управления релизом — создавать, тестировать и доставлять новые возможности, которые будут удовлетворять все продуктовые требования и намеченные цели.

Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.

Что включает процесс управления релизом?

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

Процесс управления релизом может включать следующие этапы:

• Планирование. Весь путь продукта начинается с его планирования и стратегии, а планирование релиза позволяет рассчитывать и определять количество спринтов или итераций. На этом этапе происходит начальная приоритезация, предварительная оценка затрат и анализ взаимозависимостей. К планированию привлекаются аналитики и заказчик. Планирование включает ожидания серьезных изменений в продукте, которые могут быть отражены в дорожной карте (product roadmap).
• Согласование. На этом этапе получается подтверждение ресурсов от исполнителей и заказчиков, происходит оценка бюджета релиза. Содержание релиза финально согласуется со всеми заинтересованными сторонами.
• Документирование. Этот процесс закрепления и систематизации всех процедур, где отражены, например, последние данные о новых фичах.
• Коммуникация и поддержка. Для каждого менеджера продукта очень важно не только успешно выпустить продукт или обновление, но и обеспечить налаженное взаимодействие с командой поддержки.
• Статусы готовности. Статус релиза отражается в актуальном состоянии вашего плана. Актуализация статуса помогает снизить риски и обеспечить связь с заинтересованными сторонами.
• Тестирование/Корректировки. В процессе управления релизом не обойтись без регулярных проверок и корректировок, которые помогают достигать порядка и достижения финальной цели.
• Развертывание. На этом этапе изменения передаются в эксплуатацию. Выходит новая версия продукта или сам конечный продукт.

В управлении релизом продукта могут участвовать практически все члены команды.

Product manager и Project Manager

Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.

Разбработчики

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

Маркетинг

Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.

Тестировщики

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

Служба поддержки

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

Помимо этих основных ролей, к управлению релизом могут привлекаться и другие специалисты: отдела закупок, финансисты, sales, биллинг, system engineering и др.

Почему нужно внедрять процесса управления релизам?

• Управление релизом позволяет своевременно вносить изменения в ИТ-среду без негативного влияния на качество продукта.
• Уменьшить возможные случаи несовместимости новых фич с ПО.
• Тестирование позволяет выявить и предотвратить потенциальные проблемы у пользователей.
• Релиз-менеджмент позволяет снизить количество неконтролируемых версий ПО.

Что такое Release Notes в процессе управления релизом?

Release Notes — это примечания к версии продукта, в которых описываются изменения между выпускаемой и предыдущей версиями этого продукта. Такой документ может составляться для пользователей и для внутренних команд: тестировщиков, маркетологов, службы поддержки.

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

Когда используются примечания к релизу?

Примечания к релизу распространяются вместе с продуктами. Иногда — когда продукты все еще находятся в разработке или тестировании. Документ может быть доставлен клиентам при выпуске обновления (для продуктов, которые уже были использованы клиентами).

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

Вот как выглядит страница с примечаниями к релизу у Firefox:

Как писать примечания к релизу?

Содержание документа зависит от типа релиза. Вот пример основных пунктов:

• Заголовок с названием продукта, датой релиза и его номером, версией примечания.
• Краткая информация — обзор продукта и изменений.
• Ссылки на инструкции по установке, руководство для пользователя, архив, если необходимо.
• Цели — краткий обзор целей примечаний к релизу с перечислением нового в этой версии (исправления ошибок и новые функции).
• Резюме — краткое описание ошибок и проблем.
• Шаги по устранению ошибок.
• Решение — оптимизация, которая была сделана для исправления ошибок.
• Влияние пользователей и поддержки, если необходимо.
• Примечания — все примечания относительно установки продукта, его обновлений и документации.
• Юридическая информация — лицензии, гарантии, отказ от ответственности и т.д.
• Контакты — контактная информация службы поддержки продукта.

Заключение

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

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

Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)

Как разработчику-одиночке правильно построить процесс создания и деплоя ПО — отвечают эксперты

Часто разработчики-одиночки не пользуются привычными инструментами и практиками вроде VCS, CI/CD, которые используют в командах. Спросили у экспертов, правильно ли они делают и как можно самому построить процесс разработки, сопровождения и деплоя.

Разработчик-одиночка в общем случае мало чем отличается от команды разработчиков с точки зрения построения собственных процессов. В случае с одним человеком, который работает над каким-то продуктом, такой разработчик одновременно берёт на себя все обязанности по работе над продуктом в виде полного цикла «заботы» о нём:

• планирование и дизайн продукта, разметка целевой аудитории;
• написание первичной версии приложения;
• тестирование первичной версии самостоятельно или с помощью приятелей и друзей;
• вторичная — «релизная» — версия приложения, исправленная с учётом тестирования первичной версии;
• финальное тестирование;
• релиз ПО ограниченному кругу пользователей для сбора дальнейшего фидбека;
• дальнейшее изменение продукта в соответствии с нуждами пользователей и вечный цикл поддержки продукта после его финального релиза.

По большому счёту, разработка ПО — это цикличный процесс с определёнными фазами. Работа непосредственно над продуктом сменяется сбором фидбека. После этого происходит выпуск новой версии, снова сбор фидбека, снова работа над продуктом.

Именно с точки зрения цикличной работы над продуктом, имеет смысл использовать следующие процессы при работе над ним одному человеку:

1. Обязательно использовать VCS (например, приватный репозиторий на GitHub) – поможет следить за версиями продукта, понимать разницу между предыдущим и следующим релизом, а также даёт возможность разделять стабильные релизы от нестабильного кода, над которым в данный момент ведётся работа.
2. Присваивать версии по системе Semantical Versioning — позволит выработать дисциплину относительно размера изменений в продукте. Значительные изменения выпускаются гораздо реже (особенно, если проект поддерживается одним человеком), чем небольшие правки маленьких ошибок.
3. Важно самому тестировать собственный продукт после добавления определённого количества возможностей в продукт. Либо попросить знакомых сделать это вместе с вами, чтобы получить больше сторонних мнений (не принципиально, что такие тестеры не являются целевой аудиторией — главное не UI/UX фидбек, а механическое тестирование функций).
4. Придётся самостоятельно общаться с пользователями проекта. Это может быть почтовое общение через почту поддержки, а может быть и через специальную площадку для фидбека о продукте. Главное — определиться с максимальным временем ответа, чтобы пользователи не ждали долгого ответа и знали, что им ответят в течение, например, 72 часов.
5. Если разработчик, работающий над проектом один, не пользуется средствами трекинга задач для своего продукта, то ему могут помочь простые маркеры TODO и FIXME в собственном коде. Современные редакторы (например, VSCode) позволяют анализировать код и создавать деревья TODO и FIXME, с помощью которых можно отслеживать всё, что хотелось бы рано или поздно реализовать или изменить в продукте. Такие маркеры — это часть натуральной документации кода, которая позволит одиночке не забыть о том, в какую сторону движется код.
6. В CI/CD нет необходимости, если работаешь один (по крайней мере до первого релиза точно). Некоторые процессы можно автоматизировать, но это далеко не обязательно делать с помощью тяжеловесных облачных сервисов CI/CD — автоматизацию можно выполнить в виде ряда скриптов, которые будут брать на себя основную тяжёлую рутинную работу. К тому же, локальные скрипты автоматизации — это бесплатно.

В наши дни я не могу представить себе процесс написания кода без Git. Даже если работаю один над пет-проектом.

Во-первых, я всегда знаю какие файлы я редактировал и что именно я в них менял. Это позволяет править код без страха, и гораздо легче находить причины неработоспособности кода. Любые изменения видно после долгого перерыва работы над проектом и даже после перезагрузки компьютера. Что невозможно при использовании ctrl + z.

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

Также, без системы контроля версий невозможно реализовать деплой сайта или приложения. Только если написать скрипт, который будет полностью перезаливать все файлы на сервер по FTP или SSH. Но такой процесс будет долгим и сложным – в любой момент соединение может оборваться и придётся делать всё заново. А с наличием Git, можно как минимум подключиться к серверу и сделать git pull . Когда-то мы даже использовали такой подход в продакшене.

Однако, это было до того, как веб-приложения стали нуждаться в установке зависимостей и сборке. Но и сейчас можно достаточно легко написать скрипт, например на bash, который будет клонировать новую версию проекта в отдельную папку, делать npm install , npm run build и менять символическую ссылку. А в случае проблем, запускать скрипт переключения символической ссылки на папку с предыдущей версией. Деплой на коленке готов.

Во избежание проблем с самописными решениями, я могу посоветовать воспользоваться утилитой Ansistrano. Она делает всё, что описано выше и при этом заходить на сервер не обязательно. Можно запустить скрипт прямо со своей машине. А сценарии деплоя и отката описываются в декларативных yml-файлах. Плюс, все действия идемпотенты и есть гибкие настройки: ветка, тег, коммит с которых производить деплой, количество сохраняемы резервных копий и так далее.

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

Если пойти чуть дальше, то можно освоить базовые функции Bitbucket Pipelines или GitHub Actions. Скрипты у них тоже пишутся в yml-файлах, только синтаксис везде разный. Но плюсом получаешь заготовленные сценарии, которые, например умеет использовать кеши npm, что значительно ускоряют процесс, и много других фич. Так же можно организовать автоматический деплой по мерджу в master или добавлению тэга. И это уже будут настоящие CI/CD.

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

Каждый случай индивидуален. Все зависит от объема работ, процесса согласования результатов, сроков поддержки, модернизации и многих других факторов. Зачастую кажется, что все эти системы контроля версий только увеличивают время на разработку.

Например, когда проект небольшой и есть четкое ТЗ, подробно покрывающее потребность заказчика и выполнимое в конкретный отведенный срок без возможности дальнейшей модернизации – все эти дополнительные сложности могут быть и не нужны. Написал на локале, показал заказчику, сдал проект и доволен. Но даже в таком случае системы контроля версий не будут лишними. Они могут застраховать разработчика от нечаянного удаления проекта или возврата к коду, который ранее казался неправильным (откат к прошлой версии). Но опять же если мы пишем калькулятор, то это не нужно.

Но такие проекты существуют только в идеальном сферическом мире, в вакууме. Чаще всего заказчик сам не знает, что конкретно ему нужно. После выполнения проекта по ТЗ фантазия заказчика только начинает разыгрываться, и он просит добавить в свой продукт все больше и больше фич.

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

Для более крупных проектов контроль версий просто необходим, даже если разработчик всего один. Так как заказчик, с которым программист очень приятно и продуктивно поработал год назад, может вернуться и предложить новое сотрудничество. А с тех пор ноутбук мог умереть, у заказчика мог умереть сервер и вообще «метеорит упал на Челябинск». Нынешние бесплатные системы контроля версий облачные и вероятность потерять с них данные достаточно мала – следовательно даже через год можно вернуться к внесению новых фич к старому софту.

Что касается CI\CD – его необходимость также индивидуальна для каждого проекта. Этот инструмент очень сократит время при непрерывной разработке (когда с первого прототипа и до конечного варианта софт уже используется заказчиком). Все опять же зависит от объема. Если это калькулятор и его используют 1 раз в день – можно остановить работу своего приложения и на флешке поставить новую версию. Но когда софт большой, состоит из множества модулей и нагрузка на него непрерывна, то процесс обновления может занять значительное время. В этом случае даже соло программисту стоит задуматься об автоматизации этого процесса (включая тестирование, дабы не выкатить случайно код, который все положит).

Резюмируя, хочу сказать, что эти общепринятые инструменты нужны не только для организации командной разработки, а в первую очередь для увеличения качества кода, его сохранности и ускорения развертывания его у заказчика. И целесообразность их использования зависит исключительно от самого проекта. Если проект на неделю – не стоит и заморачиваться, а в случае, если проект будет обеспечивать стабильным доходом разработчика многие годы – не поленитесь обезопасить свой доход.

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

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

Системы CI\CD также обязательны к применению, важно лишь правильно автоматизировать выполнение наиболее частых и повторяющихся действий и в целом изначально закладывать возможности для полной автоматизации сборки и публикации артефактов проекта.

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

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

Полученный опыт позволит в дальнейшем в кратчайшие сроки включиться в работу любых команд в качестве эффективного и востребованного специалиста.