Что такое релиз в программировании
Релиз (программное обеспечение)
Релиз (жарг. от англ. release — выпуск) — выпуск окончательной версии программы — готового для использования продукта. В релизе обычно собирают все версии и обновления, и выпускают конечный продукт со всеми исправлениями, который не нужно обновлять, так как он является последней версией ПО.
Управление релизами
Релиз — это набор новых и/или измененных конфигурационных единиц, в отношении которых осуществлено тестирование и которые рекомендованы для использования одновременно.
Цель процесса управления релизами является консолидация, структурирование и оптимизация всех изменений или обновлений, а также снижение риска при переводе сервиса на новый качественный уровень. Для достижения поставленной цели необходимо правильно распределить имеющиеся ресурсы и рассчитать баланс между сроками, которые отведены для внедрения всех обновлений, и временем, необходимым для подготовки внесения данных изменений.
Процесс Управления релизами состоит из трёх этапов:
На каждом предприятии процесс Управления релизами в той или иной степени исполняется и частично функционирует. Поэтому основной задачей внедрения данного процесса становится консолидация, структурирование и систематизация всех имеющихся компонентов процесса, их дополнение, а также описание процедур реализации существующих версий продуктов. Это позволит в дальнейшем разработать ряд так называемых корпоративных стандартов состава программно технических средств и процедур по их установке, которые в дальнейшем значительно упростят выполнение связанных процессов и сократят занятость высококвалифицированных специалистов.
Задача внедрения данного процесса значительно упростится благодаря функционирующему в организации процессу Управления конфигурациями, итогом которого является актуальная База данных Учётных Элементов (CMDB), в которую включены и описания всех используемых версий компонентов систем информационных технологий. Внедрение данного процесса позволит в дальнейшем так же вести централизованную Библиотеку версий программного обеспечения (DSL); склад горячей замены оборудования (DHS); а в некоторых случаях и специализированную библиотеку технической документации.
В случае успешного и правильного внедрения процесса Управления релизами пользователи получат:
Отказ от реализации данного процесса приведёт к:
Успешное построение процесса Управления релизами во многом зависит от правильности реализации процесса Управления изменениями. Поэтому в некоторых случаях рекомендуется проводить комплексное внедрение этих двух процессов. Кроме того, немаловажную роль играет и построение такого процесса как Управление конфигурациями, который необходим для своевременной регистрации всех изменений в Базе данных Учётных элементов
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Стадии разработки программного обеспечения
Стадии разработки программного продукта — это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей. Разработка ПО начинается с первоначального этапа разработки (стадия «пре-альфа») и продолжается стадиями, на которых продукт дорабатывается и модернизируется. Финальным этапом этого процесса становится выпуск на рынок окончательной версии программного обеспечения («общедоступного релиза»). [Источник 1]
Различают следующие стадии разработки программного обеспечения: пре-альфа, альфа, бета, релиз-кандидат, релиз и прекращение поддержки.
Содержание
Пре-альфа
Pre-alpha относится ко всем действиям, выполняемым во время разработки программного проекта перед его формальным тестированием. Эти мероприятия могут включать анализ требований, разработку программного обеспечения и модульное тестирование. В типичной разработке с открытым исходным кодом существует несколько типов предварительных альфа-версий. «Milestone» (англ. Этап) версии включают в себя определенные функции и выпускаются как только разработка функционала завершена.
Альфа
Альфа-этап жизненного цикла выпуска ПО — это первая фаза начала тестирования программного обеспечения (альфа — первая буква греческого алфавита). На этом этапе разработчики обычно тестируют программное обеспечение с использованием техники «белого ящика». Затем дополнительная проверка выполняется с использованием методов «черного ящика» или «серого ящика» другой группой тестирования. Переход к тестированию методом «черного ящика» внутри организации известен как альфа-релиз и представляет собой метод тестирования программного обеспечения, посредством которого анализируется функциональность ПО без вмешательства в его внутреннюю структуру (программный код).
Бета, названная в честь второй буквы греческого алфавита, является следующей фазой разработки программного обеспечения после альфа. Бета-этап обычно начинается, когда программное обеспечение полнофункционально, но, вероятно, содержит ряд известных или неизвестных ошибок. Программное обеспечение на бета-этапе, как правило, содержит больше ошибок, чем готовое программное обеспечение, а также проблемы с производительностью и может вызывать сбои или потери данных.
Бета-тестирование также концентрирует внимание на снижении негативного воздействия ПО на пользователей, поэтому оно также зачастую включает тесты на удобность использования ПО. Процесс доставки бета-версии пользователям называется бета-выпуском, и обычно это становится первым разом, когда новое ПО становится доступно вне организации, которая его разработала.
Релиз-кандидат
RC (англ. Release Candidate — Релиз-кандидат) — бета-версия, которая имеет потенциал к становлению готовым к выпуску конечным продуктом, но только если не выявятся какие-либо значительные ошибки. На этом этапе стабилизации продукта все функции продукта уже были спроектированы, запрограммированы и протестированы на одном или же нескольких бета-циклах и без каких-либо критических ошибок.
Релиз
Этап публичного выпуска программного обеспечения называется релизом. После выпуска программное обеспечение обычно называется «стабильным выпуском». Формальный термин часто зависит от метода выпуска: физических носителей, онлайновой версии или веб-приложения.
Производственный релиз
RTM (англ. Release to Manufacturing — Производственный релиз) — этап, также известный как «выход на золото», который начинается когда программный продукт готов к поставке. Сборка может быть подписана цифровой подписью, позволяя конечному пользователю проверить целостность и подлинность покупки программного обеспечения. Копия сборки RTM отправляется для массового дублирования, если это применимо для данной сборки. RTM предшествует общей доступности (GA), когда продукт становится выпущен публично.
Общая доступность
GA (англ. General Availability — Общая доступность) — это этап, на котором все необходимые коммерциализационные мероприятия завершены, а программный продукт доступен для приобретения, в зависимости, однако, от языка, региона, наличия электронных средств и доступности носителей. Коммерциализация может включать в себя тесты безопасности и соответствия, а также локализацию и доступность по всему миру.
В некоторых случаях время между RTM (выпуск в производство) и GA может составлять от недели до нескольких месяцев, прежде чем можно будет объявить общедоступный выпуск из-за времени, необходимого для завершения всех коммерческих процессов, требуемых GA. На этом этапе считается, что программа «вышла в прямом эфире». Такая программа считается надежной, свободной от серьезных ошибок, готовой для широкого доступа через интернет или тиражирования на физических носителях.
Сетевой релиз
RTW (англ. Release to Web — Сетевой релиз) — этот этап релиза с целью распространения использует сеть Интернет. В случае с сетевым релизом изготовитель не производит никаких физических носителей. Сетевые релизы становятся все более распространенными по мере роста использования Интернета.
Прекращение поддержки
Когда программное обеспечение больше не продается или не поддерживается разработчиками, то считают, что продукт достиг конца своего срока службы. Но лояльность пользователей может продолжаться в течение времени, даже задолго после того, как платформа определённого ПО устарела (например, Atari ST и Sinclair ZX Spectrum).
Всë, что вам нужно знать об управлении релизами
В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании 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 предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.
Подведем итоги
Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:
Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.
Стадии разработки программного обеспечения
В разработке программного обеспечения, стадии разработки программного обеспечения используются для описания степени готовности программного продукта. Также стадия разработки может отражать количество реализованных функций, запланированных для определённой версии программы. Стадии либо могут быть официально объявлены и регламентируются разработчиками, либо иногда этот термин используется неофициально для описания состояния продукта. Следует отметить, что стадии Beta и Alpha (Pre-Alpha) не являются показателями нестабильности релиза так как присваиваются программе один раз или один раз за серию (серией, в данном случае, считается число до первой точки), в зависимости от системы разработки. Они могут присваиваться нескольким релизам подряд. Релизом в данном случае считается завершённая версия (см. Релиз (программное обеспечение)).
Содержание
Этапы разработки
Этапы разработки Milestone — каждому этапу присваивается порядковый номер (1, 2, 3 и т. д.). Например: «Компания сделала продукт, который находится в стадии разработки. Сейчас у него этап разработки Milestone 1.». Это может быть как пре-альфа или бета, так и ранний этап разработки (раньше пре-альфы). Некоторые этапы разработки могут помечаться как «pre-». Например pre-Milestone 1.
Пре-альфа
Начальная стадия разработки — Период времени со старта разработки до выхода стадии Альфа (или до любой другой, если стадии Альфа нет). Также так называются программы, не вышедшие еще в стадию альфа или бета, но прошедшие стадию разработки, для первичной оценки функциональных возможностей в действии. В отличие от альфа и бета версий, пре-альфа может включать в себя не весь спектр функциональных возможностей программы. В этом случае, подразумеваются все действия выполняемые во время проектирования и разработки программы вплоть до тестирования. К таким действиям относятся — разработка дизайна, анализ требований, собственно разработка приложения, а также отладка отдельных модулей.
Альфа
Внутреннее тестирование — Стадия начала тестирования программы в целом специалистами-тестерами, обычно не разработчиками программного продукта, но, как правило, внутри организации или сообществе разрабатывающих продукт. Также это может быть стадия добавления новых функциональных возможностей. Программы на данной стадии могут применяться только для ознакомления с будущими возможностями.
Публичное тестирование — Стадия активного бета-тестирования и отладки программы, прошедшей альфа-тестирование (если таковое было). Программы этого уровня могут быть использованы другими разработчиками программного обеспечения для испытания совместимости. Тем не менее, программы этого этапа могут содержать достаточно большое количество ошибок.
Поскольку бета-продукт не является финальной версией, и публичное тестирование производится на страх и риск пользователя, производитель не несёт никакой ответственности за ущерб, причинённый в результате использования бета-версии. Таким образом, многие производители уходят от ответственности, предоставляя пользователям только бета-версии продукта. Так, ICQ в версии 2003 года использовала этот трюк, выпустив 2003b (b означает бета) версию этого интернет-мессенджера. Финальной версии ICQ 2003 так и не появилось, вместо этого два года спустя вышли версии ICQ 4 и ICQ 5.
Beta Escrow
Стадия бета-тестирования, релиз-кандидат на Beta.
Релиз-кандидат
Релиз-кандидат или RC (англ. release candidate ), Пре-релиз или Pre — стадия-кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексное тестирование, благодаря чему были исправлены все найденные критические ошибки. Но в то же время существует вероятность выявления ещё некоторого числа ошибок, не замеченных при тестировании.
RC Escrow
Релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.
Релиз
Релиз или RTM (англ. release to manufacturing промышленное издание) — издание продукта, готового к тиражированию. Это стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки, но существует вероятность появления новых, ранее не замеченных, ошибок. RTM предшествует общей доступности (GA), когда продукт выпущен для общественности.
RTM Escrow
Последний этап разработки продукта, который готов стать RTM-релизом.
Пост-релиз
Пост-релиз или Post-RTM (англ. post-release to manufacturing ), издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта. Такие релизы не выпускаются на продажу, а раздаются бета-тестировщикам. Это издание может быть либо стабильным (если не замечено ошибок), либо с ошибками.
Общая доступность
См. также
Ссылки
Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)
CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML
Полезное
Смотреть что такое «Стадии разработки программного обеспечения» в других словарях:
Цикл разработки программного обеспечения — Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения … Википедия
Процесс разработки программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • … Википедия
Управление разработкой программного обеспечения — (англ. Software project management) особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по… … Википедия
жизненный цикл программного обеспечения — 3.7 жизненный цикл программного обеспечения; жизненный цикл ПО (software lifecycle): Последовательность следующих друг за другом процессов создания и использования программного обеспечения программируемой связанной с безопасностью здания или… … Словарь-справочник терминов нормативно-технической документации
Бережливая разработка программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
жизненный цикл программного обеспечения — … Справочник технического переводчика
Нумерация версий программного обеспечения — Наиболее распространённый в настоящее время способ нумерации версий Жизненный цикл успешной компьютерной программы может быть очень долгим; изменения в программе бывают разными от исправления ошибки до полного переписывания. В бол … Википедия
Жизненный цикл программного обеспечения — (ПО) период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл процесс построения и развития ПО. Содержание 1 Стандарты… … Википедия
Стресс-тестирование программного обеспечения — Стресс тестирование (англ. Stress Testing) один из видов тестирования программного обеспечения, которое оценивает надёжность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс тестирование особенно… … Википедия
Аспектно-ориентированная разработка программного обеспечения — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия