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

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

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

Существует три типа релизов:

Основной (Major).

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

Минорный (Minor).

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

Патч или исправление (Patch).

Это незначительные улучшения или исправления багов, которые негативно влияют на эффективность программного продукта. То есть это совсем небольшой объем обновлений, который при загрузке не будет много весить, как при глобальном изменении. В описании версии в нумерации добавляется и изменяется третья цифра: 3.1.2 → 3.1.3 и т.д.

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

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

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

Release To Manufacturing – RTM–версия, то есть финальная версия программного продукта. Она достаточно стабильная, прошла все этапы проверки, которые подтвердили её соответствие требованиям. А это в свою очередь значит, что программа может быть доступна для массового розничного распространения.

Кроме того, RTM может быть использовано и в других контекстах. Например, это может значить, что ПО поставили заказчику для установки на компьютеры или другое рабочее оборудование. Причем совершенно не обязательно, что Release To Manufacturing будет указывать на объем поставки или его механизм. Он отражает тот факт, что размер и качество данного продукта достаточный для того, чтобы его могли использовать юзеры.

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

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

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

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

Release to web – выпуск продукта в Сеть. Веб–релиз выступает в качестве средства доставки ПО, то есть благодаря ему оно распространяется в интернете. Это наиболее распространенная концепция доставки продукта до конечного потребителя в наше время, потому что она не требует использования физических носителей, таких как диски или флешки. Для распространения существуют официальные сайты, где можно купить лицензию на программу или магазины приложений.

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

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

Обычно контроль релиза имеет следующие этапы:

Планирование.

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

Дизайн и разработка.

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

Сборка.

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

Тестирование.

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

Документация.

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

Управление изменениями.

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

Утверждение релиза.

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

Распределение и установка.

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

Отзыв и корректировка.

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

Коммуникация.

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

Архивирование.

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

Оценка процесса.

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

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

Повлиять на частоту релизов может множество факторов.

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

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

Скорость и объем.

• При частых релизах объем изменений небольшой, поэтому это позволяет провести их быструю проверку и внедрение. Обычно это 1-2 обновления, которые улучшают какую–то из функций, либо устраняют обнаруженные ошибки.

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

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

• При редких релизах риск возникновения и пропуска ошибок выше из–за большого объема данных.

Обратная связь.

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

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

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

Стабильность.

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

• Если релиз осуществляется слишком редко, то может сложиться впечатление, что разработчиков не заботит судьба продукта, а значит, если с ним возникнут проблемы, то вряд ли кто–то возьмется за их решение.

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

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

Затраты на обучение и поддержку.

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

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

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

Процессы разработки.

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

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

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

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

Agile и DevOps.

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

Непрерывная интеграция.

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

Непрерывная доставка.

Процесс доставки ПО до стадии готовности к релизу тоже можно автоматизировать. Это дает возможность оптимизировать разработку и внедрение изменений.

Автоматизированное тестирование.

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

Микросервисная архитектура.

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

Feature flags или toggle switches.

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

Мониторинг и обратная связь.

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

Конфигурация.

Благодаря этому можно без затруднений вносить изменения в различные части системы.

Стремление к инновациям.

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

Взаимодействие между командой разработчиков и заказчиком.

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

При соблюдении этих условий от частых релизов действительно будет толк.

Для того, чтобы осуществлять обновление продукта редко, необходимо иметь следующие условия:

Стабильность.

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

Сложности в обновлении.

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

Глобальные функциональные обновления.

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

Высокие затраты на обучение пользователей.

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

Ограничения.

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

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

Ограниченные ресурсы на поддержку.

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

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