Релизная версия что это

Релиз (программное обеспечение)

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

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

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

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

Процесс Управления релизами состоит из трёх этапов:

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

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

Задача внедрения данного процесса значительно упростится благодаря функционирующему в организации процессу Управления конфигурациями, итогом которого является актуальная База данных Учётных Элементов (CMDB), в которую включены и описания всех используемых версий компонентов систем информационных технологий. Внедрение данного процесса позволит в дальнейшем так же вести централизованную Библиотеку версий программного обеспечения (DSL); склад горячей замены оборудования (DHS); а в некоторых случаях и специализированную библиотеку технической документации.

В случае успешного и правильного внедрения процесса Управления релизами пользователи получат:

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

Отказ от реализации данного процесса приведёт к:

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

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

Что значит альфа и бета версия, RC, релиз?

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

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

Альфа (Alpha)
Приставка «альфа» присваивается программам, которые тестируются внутри фирмы-разработчика. Альфа-тестирование проводят в основном специалисты-тестеры. Использовать альфа-версии также не рекомендуется, так как в них всё ещё присутствует много ошибок и наверняка неполный функционал. Устанавливать альфа-версии стОит только для ознакомления с будущими возможностями программ.

Бета (Beta)
Бета-версии программ – это уже практически готовые продукты, разработанные в первую очередь для тестирования конечными пользователями. Часто их распространяют бесплатно, чтобы привлечь как можно больше пользователей, и, возможно, потенциальных покупателей будущей платной версии программы. Также благодаря свободному распространению и возможности её использования, у разработчиков появляется возможность получить оценки и отзывы от пользователей. У бета-версий программ также присутствуют ошибки, возможны сбои, так что на пользователя по-прежнему ложится вся ответственность за весь ущерб, который может быть нанесён от использования «беток». Многие разработчики специально затягивают этап бета-тестирования, чтобы избегать таких рисков.

Релиз-кандидат (RC от англ. release candidate)
После альфа и бета-тестирования все возможные ошибки уже устранены и программа практически стабильна. Однако есть ещё вероятность, что обнаружатся баги, поэтому разработчики выпускают программы именно в этой версии – RC. Во многих случаях может выйти несколько версий RC – 1, 2 и т.д.

Релиз (RTM /от англ. release to manufacturing/, Final, Stable)
Это финальная версия программы, готовая к использованию. В ней исправлены практически все ошибки, она обладает полным функционалом, работа её стабильна и протестирована многими пользователями ранее.

Релизный цикл ПО для самых маленьких

В продолжение нашей серии для начинающих ИТ-шников о базовых идеях современной коммерческой разработки, поговорим о моделях релизов. Это очень обширная тема, но мы пройдемся по верхам и исключительно с позиции разработчика. Мы не будем брать экзотические случаи, когда релизы относят на флешке, закрытой в специальном контейнере, или когда релиз ровно один — в конце разработки — и на нем все заканчивается. Поговорим о популярном CI/CD, какую роль тут играет Kubernetes и почему фичи не сразу оказываются в проде.

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

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

Предыстория

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

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

Что такое CI/CD

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

Процесс, который придумали для решения этой задачи сводится по сути к двум аббревиатурам:

CI (Continuous Integration) — непрерывная интеграция — автоматическая проверка кода при внесении постоянных небольших изменений;

CD (Continuous Delivery) — непрерывная доставка — автоматическое развертывание этого кода.

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

При чем тут Kubernetes

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

К примеру, на нашем проекте в Kubernetes реализованы три среды, далее я расскажу о них подробнее:

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

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

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

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

Выкатываемся на прод

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

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

Новая версия сначала выкатывается на основное пространство и живет там какое-то время — в нашем случае порядка 40 минут (это время, необходимое на финальные тесты).

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

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

Как долго все это тянется

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

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

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

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

Версии релизов

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

S — минимальные изменения, как правило, исправление багов (изменение третьей цифры номера версии);

M — более серьезные изменения, в частности, правка БД (изменение второй цифры номера версии);

L — действительно масштабные изменения (изменение первой цифры номера версии).

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

Итоговые замечания

Разбиение на среды в Kubernetes, да и в целом детали релизного процесса здорово зависят от специфики проекта. В нашем случае это, во-первых, хоть и огромный проект, но микросервисная архитектура, а не монолит. Во-вторых, отдельные микросервисы — это изолированные инструменты. Поэтому контура получаются довольно простые и друг другу не мешают — сервису с новой фичей, развернутому на ревью-контуре, достаточно стучаться запросами на dev-контур и т.п. При этом не возникает никакой несогласованности данных, поскольку прийти другим сервисом к тем же самым данным нельзя. Это плюс по-настоящему микросервисной архитектуры, где каждый сервис работает со своей БД.

Если бы все наши микросервисы работали с одними и теми же данными или мы бы дорабатывали огромный неповоротливый монолит, структуру сред в Kubernetes пришлось бы усложнять, чтобы разные части команды не мешали друг другу, параллельно работая в разных “углах” проекта. Или пришлось бы прорабатывать какие-то руководства в стиле “как правильно добавить поле в таблицу” с учетом обратной совместимости изменений (об этом мы уже как-то писали на Хабре).

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

Какими бывают версии программ. Жизненный цикл

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

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

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

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

Основная «классификация» стадий разработки программ:

Pre-Alpha;
Alpha;
Beta;
вечная бета-версия;
Release candidate.

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

Pre-Alpha

Этапы разработки (стадии) программы делятся на несколько «шагов». Первая – это начальная. Она характеризуется периодом времени от начала работы над проектом до выхода первой альфа версии.

Pre-Alpha – это программы, которые еще не стали alpha или beta, но уже частично готовы для организации тестирования. В них реализованы основные функциональные возможности, возможно в неполной мере.

В Pre-Alpha версии подразумеваются все действия, выполняемые при проектировании приложения:

формирование дизайна;
анализ выдвинутых требований;
непосредственное написание программа;
отладка конкретных модулей.

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

Alpha

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

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

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

Бета-продукт – это не финальная версия, хоть она и является относительно стабильной. Его публичное тестирование производится на страх и риск пользователя. За последствия работы с бетой создатели не несут никакой ответственности.

Вечная бета

Есть отдельная категория программ – «вечная бета». Данное понятие было введено Тимом О’Райли. Оно характеризует ситуацию, когда приложение находится в бета-стадии неопределенное количество времени.

Механизм уместен в интернете, где у ПО имеются следующие свойства:

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

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

Release Candidate

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

Release Candidate не исключает наличие багов. Если в течение некоторого времени масштабные недоработки не обнаруживаются, проект переходит в RTM-тип.

Выпуск

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

Здесь выделяют несколько вариантов:

Выпуск в производство. Ситуация, когда проект готов к тиражированию. Стабильная версия (не альфа и не candidate) программы, прошедшая предыдущие этапы. Это и есть RTM. Термин используется тогда, когда нужно указать, что проект соответствует определенному уровню качества и готов для «выпуска в массы».
Общедоступность или GA. Маркетинговая стадия. Во время нее проводятся мероприятия, связанные с коммерциализацией. Программный продукт становится доступным для приобретения.
Веб-релиз. Это – выпуск в интернет (RTW). Средство доставки ПО, использующее для распространения интернет. Наиболее распространенная концепция в 21 веке.

После того как итоговый проект будет реализован, он начинает поддерживаться. Во время этого периода создатели выпускают к ПО патчи, а также пакеты обновления. Срок поддержки нигде не регламентирован: у некоторых приложений он длится 1-2 года, а у каких-то 5-9 лет.

P. S. Хотите знать больше? Обратите внимание на курсы по тестированию в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.