что значит релиз не требующий установки
Релиз (программное обеспечение)
Релиз (жарг. от англ. release — выпуск) — выпуск окончательной версии программы — готового для использования продукта. В релизе обычно собирают все версии и обновления, и выпускают конечный продукт со всеми исправлениями, который не нужно обновлять, так как он является последней версией ПО.
Управление релизами
Релиз — это набор новых и/или измененных конфигурационных единиц, в отношении которых осуществлено тестирование и которые рекомендованы для использования одновременно.
Цель процесса управления релизами является консолидация, структурирование и оптимизация всех изменений или обновлений, а также снижение риска при переводе сервиса на новый качественный уровень. Для достижения поставленной цели необходимо правильно распределить имеющиеся ресурсы и рассчитать баланс между сроками, которые отведены для внедрения всех обновлений, и временем, необходимым для подготовки внесения данных изменений.
Процесс Управления релизами состоит из трёх этапов:
На каждом предприятии процесс Управления релизами в той или иной степени исполняется и частично функционирует. Поэтому основной задачей внедрения данного процесса становится консолидация, структурирование и систематизация всех имеющихся компонентов процесса, их дополнение, а также описание процедур реализации существующих версий продуктов. Это позволит в дальнейшем разработать ряд так называемых корпоративных стандартов состава программно технических средств и процедур по их установке, которые в дальнейшем значительно упростят выполнение связанных процессов и сократят занятость высококвалифицированных специалистов.
Задача внедрения данного процесса значительно упростится благодаря функционирующему в организации процессу Управления конфигурациями, итогом которого является актуальная База данных Учётных Элементов (CMDB), в которую включены и описания всех используемых версий компонентов систем информационных технологий. Внедрение данного процесса позволит в дальнейшем так же вести централизованную Библиотеку версий программного обеспечения (DSL); склад горячей замены оборудования (DHS); а в некоторых случаях и специализированную библиотеку технической документации.
В случае успешного и правильного внедрения процесса Управления релизами пользователи получат:
Отказ от реализации данного процесса приведёт к:
Успешное построение процесса Управления релизами во многом зависит от правильности реализации процесса Управления изменениями. Поэтому в некоторых случаях рекомендуется проводить комплексное внедрение этих двух процессов. Кроме того, немаловажную роль играет и построение такого процесса как Управление конфигурациями, который необходим для своевременной регистрации всех изменений в Базе данных Учётных элементов
Релиз
Релиз (англ. Release) – подразумевает под собой последний выпуск программного обеспечения, это самая новая версия программного обеспечения, содержащая все изменения и обновления. В релизе содержатся новые и измененные конфигурационные единицы, в отношении которых осуществлено тестирование и которые готовы к использованию. Целью процесса управления релизами является консолидация, структурирование и оптимизация всех изменений или обновлений ПО. Также при этом снижаются риски при переходе продукта на новый качественный уровень.
Содержание
Общие сведения
Общую информацию Вы можете получить, перейдя по следующим ссылкам:
Расширенные сведения
С дополнительной информацией об этом понятии Вы можете ознакомиться ниже.
У релиза программного обеспечения есть свой жизненный цикл (см. иллюстрацию):
Пре-альфа
Первый этап жизненного цикла релиза ПО называется «Пре-альфа» (англ. Pre-alpha). Пре-альфа относится ко всем видам деятельности на этапе разработки ПО до момента тестирования. На этом этапе выполняют такие действия:
Альфа
Третий этап – «Бета» (англ. Beta). Данный этап, как правило, начинается с завершения разработки всех функций ПО. На этапе Бета в программах находят больше технических деффектов, чем на предыдущих этапах (например, скорость работы или производительность системы). Этот этап предполагает проведение тестирования эксплуатационной пригодности. Процесс предоставления пользователям бета-версии программы называется Бета-релиз. По сути, это тот этап, когда программное обеспечение становится доступным для внешних пользователей, а не только для разработчиков внутри организации.
Закрытое и открытое Бета-тестирование
Четвертый этап – «Закрытое и открытое Бета-тестирование». То есть разработчики выпускают или закрытую версию ПО, или открытую. Закрытая Бета-версия программы доступна лишь для узкого круга пользователей, которые протестируют ПО. Соответственно, открытая Бета-версия доступна широкому кругу лиц, которые могут протестировать программу по своей инициативе. После чего, они сообщают разработчикам о возникших ошибках и иногда предлагают дополнить программу какими-то функциями, которые, по их мнению, должны присутствовать в финальной версии программы. Примерами основных открытых бета-версий программ могут служить:
Тестирование открытых Бета-версий применимо в двух случаях:
Пятый этап называется «Релиз-кандидат» (англ. Release candidate, RC)- это Бета-версия продукта, который имеет достаточно потенциала для того, чтобы стать финальной версий. На этом этапе продукт станет финальным релизом, в случае, если не возникнут серьезные дефекты. На данном этапе происходит стабилизация функционирования ПО – все функции разработаны, закодированы и протестированы. Этот релиз превращается в релиз с утвержденным кодом (code complete), когда вся команда разработчиков убеждена, что ни один новый код не будет добавлен в данную программу.
Релиз для производства
Шестой этап называется «Релиз для производства» (англ. «Release to manufacturing,RTM). Термин RTM, известный также, как «становящийся золотом»(англ. Going Gold), используется, когда продукт может предоставляться конечным пользователям. Чаще всего, подразумеваются розничные продажи широкому числу покупателей. Термин RTM также может означать, что продукт был предоставлен клиентам для инсталляции на своих аппаратных устройствах. Этот термин не определяет способ и объем доставки ПО потребителям, он всего лишь указывает на то, что на этом этапе качества продукта достаточно для массового распространения. Этот этап предшествует этапу жизненного цикла релиза ПО под названием «Общедоступный Релиз».
Общедоступный Релиз
Веб-релиз
Окончание срока службы
Завершающий этап «Окончание срока службы» (англ. End-of-life). Означает, что программа больше не продается и не поддерживается. ПО морально устаревает, но иногда лояльность пользователей может продлить программе жизнь на еще какой-то промежуток времени.
Единый регламент релизного процесса
1. Термины и сокращения
Релиз
Scope freeze
Дата и время фиксации состава релиза, которые указываются в графике релизов для каждого планового релиза (HF/SP/RC):
После истечения указанного времени в состав релиза перестают приниматься задачи. Исключительные ситуации рассматриваются Руководителем направления РМ.
Финализация
Плановый релиз
Релизы, которые выпускаются в соответствии с графиком релизов и планируются заранее. К плановым релизам относятся:
Если релиз выпускается незапланированно (в срочном порядке), то ему может быть присвоен только тип extraHF, вне зависимости от типов задач, включаемых в состав этого релиза.
Внеплановый релиз
RC (Release Candidate)
Плановый мажорный релиз, в который включаются:
Нумерация релиза: x.0.0
Дополнительного согласования состава релиза не требует.
В ту неделю, на которую приходится выпуск RC, не выпускается плановый недельный SP.
На текущий момент принят курс на уход от выпуска крупных RC во избежание большого количества аварий на регионах.
Вместо RC все доработки включаются в SP.
Отдельные масштабные доработки системы могут рассматриваться для выпуска в RC.
SP (Service Pack)
Плановый еженедельный релиз, в который включаются:
Нумерация релиза: x.y.0
Выпускается еженедельно (в среду). Дополнительного согласования состава релиза не требует.
Релиз с типом SP не может выпускаться во внеплановом порядке.
HF (Hotfix)
Плановый релиз, в который включаются только подсвеченные задачи одного из следующих типов:
Аргументы, которые НЕ являются основанием для включения задач в плановый хотфикс (HF):
Если в HF требуется включение задачи с аргументами из п. 1-5, то необходимо согласовать включение (см. Включение неподходящих по критериям задач в плановые HF).
Нумерация релиза: x.y.z
Выпускается каждый понедельник и четверг (фиксация состава релиза производится утром в день выпуска релиза). Включение задач в такой релиз должно быть согласовано с Руководителем направления РМ.
Тестирование HF в релизной сборке проводится силами команд, поэтому планировать ресурсы на тестирование необходимо заранее.
Релиз с типом HF не может выпускаться во внеплановом порядке.
ExtraHF (Extra Hotfix)
Внеплановый релиз, в который включаются только следующие задачи:
Нумерация релиза: x.y.z.w
Выпускается по требованию. Требуется согласование выпуска релиза с Руководителем направления РМ.
Инцидент
Ошибка, найденная на региональных стендах (Prodlike-стенд / продуктивный стенд). Оформляется через СКУФ и создаётся из задачи проекта PROMEDSKUF.
Ошибка
Внутренная ошибка, найденная на стороне Производства на стендах разработки (в процессе разработки по задаче любого типа, либо при регрессионном тестировании релиза).
История
Задача на доработку существующей функциональности / разработку новой функциональности.
Задача
Эпик
Реестры
What’s new
Deployment Plan
Описание порядка действий (плана работ) при обновлении регионов на новую версию.
Типовой Deployment Plan Промед (стандартные операции при обновлении) приведён на странице Типовой DeploymentPlan PROMED.
План отката
Dev-стенд
Внутренний тестовый стенд, на котором ведётся тестирование задач до слития в релизную ветку. Для тестирования задач с региональными особенностями используется тестирование на региональных контейнерах (обновление происходит с использованием бота).
Командный стенд
Внутренний тестовый стенд, который используется командой разработки для тестирования разрабатываемых задач до слития в релизную ветку. Допускается использование одного командного стенда несколькими командами разработки.
На текущий момент командные стенды в процессе внедрения, ведутся пилотные версии командных стендов для нескольких команд разработки.
Основной регрессионный стенд
Внутренний тестовый стенд для регрессионного тестирования плановых релизов (еженедельных SP и RC).
На текущий момент основной регрессионный стенд ещё не внедрён в работу.
Регрессионный экспресс-стенд
Внутренний тестовый стенд для регрессионного тестирования срочных релизов (внеплановых HF).
На текущий момент регрессионный экспресс-стенд ещё не внедрён в работу.
Релизный стенд
Prodlike-стенд
Тестовый стенд региона, на котором производится тестирование финализированной сборки релиза перед согласованием установки на продуктивный стенд региона.
Prodlike-стенды регионов обновляются для тестирования релизных сборок через уведомления в почту (см. шаблон № 4 на странице Шаблоны писем-уведомлений).
Список Prodlike-стендов регионов представлен на странице https://svn.is-mis.ru/rmis_ver/promed_ver.html.
Beta-стенд
Внутренний стенд, находящийся в зоне ответственности Производства (в отличие от Prodlike-стендов, которые находятся в ЗО Эксплуатации), предназначенный для тестирования в релизной сборке региональных особенностей для регионов, у которых нет Prodlike-стенда.
Продуктивный стенд
Продуктивный стенд региона, на который финально устанавливается сборка релиза после тестирования на Prodlike-стенде региона и согласования установки сборки на продуктивный стенд.
Планирование обновлений продуктивных стендов находится в зоне ответственности Отдела эксплуатации.
Список продуктивных стендов регионов представлен на странице https://svn.is-mis.ru/rmis_ver/promed_ver.html.
2. Основные правила выпуска релизов
Релизы выпускаются (финализируются) последовательно. Плановые релизы (HF/SP/RC) выпускаются со строгим соблюдением версионности, т.е. плановый сервис-пак (SP) не финализируется до тех пор, пока не будут выпущены и влиты в него все плановые хотфиксы (HF) с меньшей версией.
Следующий по версионности внеплановый релиз (extraHF) не начинает готовиться до того, как выпущен текущий внеплановый релиз. Если в процессе подготовки текущего внепланового релиза поступает требование на выпуск нового внепланового релиза, то в первую очередь рассматривается возможность выпуска поступивших задач в текущем внеплановом релизе.
В исключительных ситуациях (если на регионе идёт период сдачи счетов, либо если регион ещё не установил актуальную версию релиза, которая требует ДТ при установке) рассматривается возможность выпуска внепланового релиза (extraHF) от версии релиза, установленной на продуктивном стенде региона. Подробнее принципы определения версии для релизов приведён на странице Шаг 1. Инициирование выпуска релиза, определение версии, состав релиза.
После установки сборки релиза на Rpodlike-стенды регионов допускается внесение правок в релизную сборку с последующим дообновлением уже обновлённых Prodlike-стендов до актуального состояния с учётом последних изменений.
После того, как релиз финализирован (см. Шаг 11. Подготовка релиза к выпуску, финализация релиза), запрещены все коммиты в релизную ветку. При нахождении критических / блокирующих ошибок инициируется выпуск внепланового хотфикса.
В процессе релизного цикла на релизной странице релиза ответственный за этап отмечает факт исполнения этапа в блоке «График подготовки релиза» в колонке «Факт выполнения»:
Всë, что вам нужно знать об управлении релизами
В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.
Что это такое управление релизом?
Управление релизами охватывает все этапы выпуска программного обеспечения, от разработки и тестирования до развертывания. Управление релизом требуется каждый раз, когда запрашивается новый продукт, или даже изменения в продукт существующий. Есть пять основных шагов по управления релизом, которые мы делаем в этой ситуации:
Планирование релиза
Этап планирования в большинстве случаев интенсивен, так как именно на этом этапе весь наш релиз организуется от начала до конца. Надёжный план релиза помогает придерживаться верного пути и обеспечивать надлежащее соблюдение стандартов и требований.
При планировании релизов мы считаем, что разработанные несколькими командами приложения нуждаются в согласованном подходе, который должен быть выпущен заранее. Именно здесь в игру вступает концепция «трейн-релиза». Следуя подходу трейн-релиза, команды могут планировать изменения на основе релизов и отправлять их в Play Store.
Самым первым шагом, ещё до того, как мы начнём реализовывать трейн-релиз, является определение временных интервалов каждого этапа. В нашем случае этап разработки — это две недели. Затем нужно определить, сколько времени вы хотите потратить на интеграционное тестирование и этапы развёртывания. Ниже наш пример интервалов:
Следующий шаг на пути к релизам — создание рабочего процесса, к которому на протяжении всего релиза могут обращаться как наши команды, так и ключевые заинтересованные стороны.
Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент «Асана» для отображения этих деталей, перечисленных ниже:
Как только план утверждается и окончательно оформляется, начинается самое интересное!
Важные аспекты планирования релизов
Создание и использование трейн-релиза звучит здорово, но поддерживать процесс в рабочем состоянии во время планирования трейн-релиза может быть непростым. Вот некоторые детали этого процесса:
Построение релиза
После того как план выпуска готов, можно приступать к тестированию продукта для релиза. Это будет фактическое «тестирование уровня пользователя» продукта на основе изложенных в плане выпуска требований.
В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.
Автоматизируя переход ветки, мы проверяем все пороговые значения производительности, бенчмарк и автоматизации из предыдущих релизов в маркет устанавливаются на текущий как основание сравнения, а трейн-релиз блокируется от дальнейших изменений.
Как только код замораживается, начинается новый цикл разработки, и все участвующие команды начинают новый спринт и продолжают разработку. Самое замечательное в трейн-релизе: все знают о следующем, запланированном релизе, и это помогает людям соответствующим образом планировать свою работу.
Релиз веток и контроль версий
Разработка продукта обычно не останавливается, когда заканчивается разработка для релиза, поэтому первое, о чем мы думаем, это как заморозить тестируемую сборку и в то же время поработать над новыми возможностями для следующего релиза. Что случится, если в сборке релизов появится ошибка? Как исправить ошибку, если вы уже добавили кучу новых вещей до того, как эта ошибка нашлась?
Именно здесь на помощь приходит хитрая стратегия ветвления, в которой есть концепция разветвления. Как следует из названия, ветвление кода означает, что точно так же, как у веток дерева, код веток до определенной точки совпадает, а затем разбивается на две копии.
Каждая ветвь может развиваться независимо от другой. В этом случае одна копия — ветка релиза — остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть «замороженная» ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.
Пользовательское приемочное тестирование
Пользовательское приемочное тестирование является наиболее важным шагом для управления релизом из-за объема собранных данных и исправлений, необходимых для того, чтобы сделать сборку именно такой, какой она должна быть для официального запуска.
Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура — пользователь. Пользователи — это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:
Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!
Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.
Подготовка и релиз
Этот шаг заключается в том, чтобы внести последние штрихи в продукт, учитывая все, что было понято при UAT. Подготовка релиза также включает в себя заключительную проверку качества командой по контролю качества. В ходе проверки группа по контролю качества проводит окончательные проверки, чтобы убедиться, что сборка соответствует минимальным стандартам приемки и бизнес-требованиям из плана релиза.
После завершения ревью релиз-группа завершит релиз для начала развертывания. Перед тем, как сборка может быть развернуто в живой среде, она должно быть утверждена соответствующими ответственными командами, такими как команда дизайна. UAT гарантирует, что результат утверждается до передачи на следующий этап.
Развертывание релиза
Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:
В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.
Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.
Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.
Анализ после релиза
Работа по управлению релизом не заканчивается, когда публикуется код, продолжаясь до тех пор, пока вы не будете готовы выпустить релиз снова. Если вы хотите, чтобы ваше приложение было успешным, ему нужно хорошее ревью, вам также нужно следить за релизом в производственной среде, чтобы исправлять ошибки, внедрять функции, которые нужны людям, и решать проблемы пользователей. Для этого мы используем Firebase Crashlytics, где отслеживаем любые сбои, требующие немедленного исправления.
Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.
Подведем итоги
Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:
Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.