Релиз в разработке программного обеспечения¶

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

¶История термина

Термин «release» пришёл из практики англоязычных компаний-разработчиков в 1960–1970-х годах, когда программное обеспечение распространялось на физических носителях. Первоначально релизом называли акт передачи ленточных накопителей или магнитных дисков с кодом заказчику или в тираж. С развитием интернета в 1990-х годах понятие сместилось в сторону публикации файлов на серверах для скачивания. В русскоязычной среде термин закрепился без перевода, поскольку кальки «выпуск» и «издание» не передавали технический оттенок, связанный с версионированием.

¶Жизненный цикл и стадии

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

• Pre-alpha — стадия активной разработки, когда функциональность не завершена.
• Alpha — версия для внутреннего тестирования, содержащая значительное число ошибок.
• Beta — версия для ограниченного круга внешних тестировщиков; функциональность заморожена, ведётся поиск дефектов.
• Release candidate (RC) — версия-кандидат, которая при отсутствии критических ошибок становится финальной.
• General availability (GA) — публичный релиз, доступный всем пользователям.

Понятие «релиз» часто применяют именно к стадии GA, однако в широком смысле релизами называют любые публикации версий, включая бета-версии.

¶Типы релизов

Релизы классифицируют по цели и аудитории:

• Мажорный (major) — содержит значительные изменения, новые возможности и может нарушать обратную совместимость. Обозначается увеличением первой цифры версии (например, 2.0).
• Минорный (minor) — добавляет улучшения и новые функции без нарушения совместимости. Обозначается второй цифрой (например, 2.1).
• Патч (patch) — исправляет ошибки и уязвимости, не добавляя новой функциональности. Обозначается третьей цифрой (например, 2.1.1).
• Кандидат в релизы (RC) — предварительная версия, претендующая на статус финальной.
• Ночной (nightly) — собирается автоматически ежедневно из актуального кода для тестирования.
• LTS (Long-Term Support) — версия с длительным сроком поддержки, предназначенная для корпоративных пользователей.

¶Процесс выпуска

Выпуск релиза — регламентированная процедура, включающая несколько этапов:

1. Замораживание кода — прекращение добавления новых функций и сосредоточение на исправлении дефектов.
2. Тестирование — проведение регрессионного, интеграционного и приёмочного тестирования.
3. Сборка — компиляция исходного кода в исполняемые артефакты.
4. Верификация — проверка соответствия собранных артефактов контрольным суммам и требованиям.
5. Публикация — размещение дистрибутивов на серверах распространения.
6. Уведомление — информирование пользователей через документацию, блоги или системы обновления.

В современных компаниях процесс автоматизируется с помощью систем непрерывной интеграции (CI/CD), таких как Jenkins, GitLab CI или GitHub Actions. Автоматизация позволяет сократить время между коммитом кода и публикацией релиза до нескольких минут.

¶Управление версиями

Для нумерации релизов широко применяется семантическое версионирование (SemVer), предложенное Томом Престон-Вернером в 2010 году. Формат версии — «мажор.минор.патч». Правила SemVer предписывают увеличивать мажорную версию при несовместимых изменениях API, минорную — при добавлении обратно совместимых функций, патч — при исправлениях ошибок. Для предварительных версий допускаются суффиксы, например, «1.0.0-rc.1».

¶Применение в различных областях

Помимо классического программного обеспечения, термин «релиз» используется в смежных сферах:

• Веб-разработка — релизом называют развёртывание новой версии сайта или веб-приложения на production-сервере.
• Мобильные приложения — публикация в магазинах приложений (App Store, Google Play) после прохождения модерации.
• Игровая индустрия — выпуск видеоигр на физических носителях или в цифровых магазинах; отдельно выделяют релиз на консолях и ПК.
• Открытое программное обеспечение — публикация исходного кода и бинарных сборок в публичных репозиториях.
• Операционные системы — выпуск новых редакций ОС (например, релизы дистрибутивов Linux, таких как Ubuntu, выходят каждые шесть месяцев).

¶Каналы распространения

Способы доставки релизов до пользователей эволюционировали от физических носителей к цифровым:

• Физические носители — компакт-диски, DVD, флеш-накопители, исторически использовавшиеся для коробочных версий.
• Цифровые магазины — централизованные платформы (Steam, Epic Games Store, Microsoft Store).
• Репозитории пакетов — в Linux-экосистемах (APT, YUM, Homebrew) релизы распространяются через менеджеры пакетов.
• Стриминг-обновления — механизм доставки обновлений по сети, используемый в ОС и приложениях.

¶Интересные факты

• В компании Microsoft для обозначения готовой версии используют аббревиатуру RTM (Release to Manufacturing), что исторически означало передачу кода производителю компакт-дисков.
• В сообществе разработчиков открытого ПО существует традиция называть релизы именами (например, дистрибутивы Ubuntu именуются по алфавиту прилагательными и названиями животных).
• Крупнейшие релизы программного обеспечения могут сопровождаться «днём обновления» (Patch Tuesday) — во второй вторник каждого месяца Microsoft публикует накопительные обновления для своих продуктов.
• Некоторые проекты используют модель «катящегося релиза» (rolling release), при которой обновления выходят непрерывно без разделения на дискретные версии; такой подход применяют Arch Linux и Chrome.

¶Критика и сложности

Практика частых релизов подвергается критике за риск внесения регрессий — ошибок, возникающих после обновления. В ответ на это компании внедряют каналы постепенного развёртывания (canary release), когда новая версия сначала доступна небольшой группе пользователей, а затем распространяется шире. Другой проблемой является «релизная гонка» — стремление выпустить версию к определённой дате в ущерб качеству, что приводит к техническому долгу и накоплению ошибок в последующих патчах.