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

Управлять релизом просто: правила и этапы 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 и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)

• релиз
• релиз-менеджмент
• управление проектом
• управление продуктами
• управление задачами

• Блог компании Hygger
• Высокая производительность
• Управление разработкой
• Управление проектами
• Управление продуктом

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

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

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

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

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

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

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

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

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

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/).

• релиз
• релиз-менеджмент

Три ингредиента идеальных релизов ПО

Соедините одну часть архитектуры с двумя частями командной работы. Добавьте автоматизацию и перемешайте.

Автор: Dan Radigan

Просмотр тем

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

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

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

Идеальный релиз программного обеспечения начинается с модульной архитектуры

Какое бы ПО вы ни разрабатывали, лучше всего выпускать продукт чаще и с минимальными усилиями. Чтобы органично вписать релизы в культуру Agile, команда может создать модульную архитектуру (либо провести рефакторизацию существующей). Вместо того чтобы работать над одним внушительным приложением (таким как упомянутый ранее монолит), разбейте его на ранних этапах программы на несколько фрагментов-модулей. Объедините схожие функции в небольшие приложения или компоненты и составьте четкие планы («контракты») API для каждого приложения или компонента. Эти API можно подвергать автоматическому тестированию с каждой новой сборкой, чтобы убедиться в совместимости и сократить риски на этапе выпуска программного обеспечения.

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

Идеальные релизы программного обеспечения строятся на взаимопонимании

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

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

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

Следующие рекомендации будут полезными для операционных команд, сотрудничающих с разработчиками.

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

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

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

Автоматизация, автоматизация и еще раз автоматизация!

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

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

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

Идеальные релизы программного обеспечения — отличная штука!

Отличительная черта agile-разработки заключается в том, что код должен поддерживаться в состоянии готовности к релизу.

Как это делается

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

Поскольку мы являемся разработчиками ПО, на первом плане нашего цикла инновации должен находиться релиз ПО. С кодом, который мы написали, будут взаимодействовать клиенты, и они будут делиться своими впечатлениями. Круто! Если выпуск версий станет вашим привычным занятием в рабочие дни, вам будет проще выводить код в рабочую среду и с гордостью произносить: «Это мой код!»

IT для неайтишников: Управление релизами, когда и зачем нужно?

Как вообще появилась идея рассказывать о процессе управления релизами для неайтишников? Тема родилась из тех проблем, которые порождаются «Самоорганизацией в ИТ». Процесс управления релизами, с одной стороны хорошо доступен для понимания не техническими специалистами, с другой стороны задаёт эффективную систему ограничений, которая не даёт разработчикам свернуть не туда и понаделать ошибок. Собственно, что такое релиз и зачем им управлять.

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

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

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

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

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

Делаем непонятное понятным

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

За счет такого уровня «абстракции» уходит привязка к определённой области (бухгалтерия, производство, логистика либо иное), уходят специфические термины, вместо этого появляется понятная даже ребёнку схема взаимодействия.

Мы же не будем упрощать все до «волшебных гномиков», вместо них мы используем другую понятную для бизнеса аналогию. Если мы говорим о разработке и доработке информационных систем, то она строится вокруг работы разработчиков программного обеспечения. Что делает разработчик? Если говорить совсем просто, то пишет программный код. Точнее фрагменты кода для весьма большой системы, которые внутри этой системы взаимодействуют между собой. В чем-то это похоже на изменение регламентов на виды работ на каком-то большом производстве.

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

Стенд разработки

Представим, что у нас есть некоторое крупное производство, на нем есть много процессов и регламентов, которые как-то связаны между собой. Чем именно занимается производство не так уж и важно, каждый может представить что-то своё, суть от этого не поменяется. Когда мы что-то «неудачно» меняем в процессах и регламентах, производство может встать либо начать работать неэффективно.

Чаще всего это происходит из-за конфликтов в регламентах и взаимосвязанных процессах. Кто-то кому-то что-то не предоставил. Где-то изменилась длительность процесса, съехал весь график производства, возникли простои. Где-то с чем-то не состыковались и всё встало. Если мы говорим о переработке регламентов на масштабных производствах, то это может быть приключением длительностью в годы. Пока всё отладят и исправят недоработки…

В целом, в разработке программного обеспечения всё где-то так. Но процесс идет много быстрее за счет «интерактивного программирования». Программист может быстро собрать свой проект и запустить код, чтобы посмотреть, как он работает. Быстрее выявляются недоработки, быстрее идет работа.

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

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

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

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

Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?

Программист: ну, представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, вылетает сообщение об ошибке «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик Ржевский умер.» Выясняется, что он в следующей главе облокачивается о столб, которого уже нет.

Чтобы можно было посмотреть, как изменения работают друг с другом, придумали стенд разработки. Тот цифровой двойник, который используется индивидуально одним проектировщиком, называют «локальным стендом», обычно он даже размещается на локальном (персональном) компьютере сотрудника. Стенд разработки — это тот цифровой двойник, на котором проверяется работа при внесении сразу нескольких изменений.

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

Здесь же возникает вторая проблема. То, что работает локально у проектировщика либо на стенде разработки, необязательно будет работать после внедрения на реальном производстве (продуктиве). Потому что на реальном предприятии может не хватать каких-то изменений, которые были на стенде разработки. Либо даже наоборот, там уже будут какие-то изменения, которых не было на локальном стенде либо стенде разработки. Проектировщиков же работает много.

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

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

Система контроля версий

Что такое система контроля версий? Представьте, что вам с кем-то нужно совместно работать над документом. Вы берете текущее состояние документа и делаете от него «ветку», в которую вносите изменения. То есть получаете свою версию документа. А потом у вас есть возможность слить несколько веток изменений в одну, то есть получить итоговый документ.

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

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

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

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

Теперь возвращаемся ко второй проблеме.

Релиз и тестовый стенд

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

Тестовый стенд — это тот цифровой двойник предприятия, на котором мы будем смотреть не отдельные ветки изменений, а целого пакета изменений — релиза. Производство большое, регламентов и процессов на нем много, между ними есть сложные связи. Скорее всего, где-то что-то не учли, где-то что-то работает не так, как изначально задумывалось. Это все нужно проверить.

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

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

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

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

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

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

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

Предпродуктовый стенд

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

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

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

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

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

Внедрение релиза

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

Еще нужно описывать состав релиза. Хотя бы какие изменения в него вошли и какие недоработки в рамках него исправляются. Такой документ называют Release Notes (записка к релизу). По таким документам можно восстановить историю релизов.

Что произойдёт, если забыть предупредить о том, что внедряется релиз и о том, что изменится после релиза? Все очень просто, люди будут пытаться работать по старым регламентам и процессам, а любые отклонения от них воспринимать, как ошибку. Таких ошибок в виде инцидентов выявят очень много, их разбор — это деньги и ресурсы.

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

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

Такое часто практикуют при внедрении масштабных проектов, когда разом внедряется много крупных изменений и есть риски все сломать на продуктиве. В IT есть шутка, что быстро поднятое упавшим не считается (упало — полностью сломалось).

Кроме того, у релизов есть еще номера, в которых кодируется масштабы и срочность внедряемых изменений. Например XX.YY.ZZ, здесь XX — номер для масштабного внедрения, которое затрагивает очень много процессов, YY — номер для рядового внедрения, которое может происходить даже на ежедневной либо ежемесячной основе, ZZ — номер сверхсрочных внедрений, скорее всего это исправление критичных ошибок либо очень срочные изменения для бизнеса.

То есть номер 2.5.14 можно читать как: «После второго раза, как все начали работать совсем по-другому, было сделано 5 средних изменений в процессах работы, после чего успели 14 раз внедрить исправления по критическим ошибкам».

Эксплуатация релиза

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

Например, номер релиза 2.5.14 говорит, что нам понадобилось 14 сверхсрочных внедрений, скорее всего часть из них была связанна с аварийными ситуациями. Много это либо мало зависит от частоты средних по масштабам изменений. Если они происходят раз в год, то скорее всего внедрялись небольшие, но важные для бизнеса изменения. Если они происходят раз в месяц либо раз в неделю, то в пору задуматься о качестве релиза. Скорее всего, процесс тестирования сломан и не работает. А еще можно почитать Release Notes для каждого релиза, чтобы понять, в чем было дело.

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

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

Подводя итоги

Мы сделали шаг в сторону от терминологии мира информационных технологий и простыми словами объяснили, что такое процесс управления релизами и зачем он нужен. Конечно, здесь процесс управления релизами описан не совсем полностью. Например, есть процесс планирования релиза. В ходе тестирования релиза существует момент «фичефриз», когда в релиз запрещают вносить изменения по новым доработкам, оставляя возможность вносить только исправление ошибок. Затем наступает момент «кодфриз», когда запрещают вносить даже исправления ошибок. То есть можно вносить исправление только по блокирующим ошибкам. Бывают ситуации, когда релиз приходится двигать по срокам.

Если в компании много разработчиков, управление становится непростой и напряжённой работой. У всех планы, сроки, лишение премий и прочие. Люди пытаются договориться, надавить, обмануть наконец. Например, внедрить новый функционал под видом исправления ошибок. Бывают курьёзы, когда разработчиков спрашивают, почему для исправления опечатки в одном слове (должна поменяться 1 строка кода), пришлось изменить 2 тысячи строк кода? Иногда ответы на этот вопрос поражают своей изворотливостью.

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

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

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

Если не смотреть за метриками, то будет не понятно нужно было ли вносить какие-то изменения либо нет. А раз так, то вообще зачем что-то разрабатывать и вносить. Возможно, просто делается какая-то бесполезная работа. Кстати, анализ Realese Notes тоже помогает выявить работу ради работы.

Иногда процесс управления релизами неверно считают частью процесса обеспечения качества (QA), хотя он больше относится к процессу управления изменениями. Такое делать нельзя, теряется контроль за метриками и управление информационным продуктом. Метрики и инциденты возникают на продуктиве, а не на стендах тестирования.

Если вы дочитали до конца, и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме:

• IT для неайтишников: Зачем оно нужно?
• IT для неайтишников: Какими бывают IT-шники? Часть 1
• IT для неайтишников: Какими бывают IT-шники? Часть 2
• IT для неайтишников: Какими бывают IT-шники? Часть 3
• IT для неайтишников: Какими бывают IT-шники? Часть 4
• IT для неайтишников: Какими бывают IT-шники? Часть 5
• IT для неайтишников: Какими бывают IT-шники? Часть 6
• IT для неайтишников: Какими бывают IT-шники? Часть 7
• IT для неайтишников: Какими бывают IT-шники? Часть 8
• IT для неайтишников: Куда исчезают программисты после 40 лет?
• IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
• IT для неайтишников: Технический долг или почему теперь всё так долго?
• IT для неайтишников: Осторожно — JSDD (Бизнес в заложниках у IT)
• IT для неайтишников: Инженеры в заложниках у бизнеса
• IT для неайтишников: Потеряли ключи от IT, что делать?
• Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
• Процессы в ИТ: Долго, дорого и не то
• Саморегуляция в ИТ: минимально допустимая эффективность работы
• Telegram-канал Записки ITBP (короткие сообщения)
• Канал на Дзен Записки ITBP (статьи среднего размера)