Релиз-кандидат (RC): что это и как его провести

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

Что такое релиз-кандидат в разработке ПО?

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

Чем бета отличается от релиз-кандидата?

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

Как версионировать релиз-кандидат?

Используйте предрелизный суффикс к версии, которую собираетесь выпускать. По семантическому версионированию дефис с идентификаторами через точку отмечает предрелиз, поэтому первый кандидат для 2.4.0 — 2.4.0-rc.1, следующий — 2.4.0-rc.2, а релиз — просто 2.4.0.

Приоритет следует спецификации: 2.4.0-rc.1 сортируется ниже 2.4.0-rc.2, а любой предрелиз ниже релиза. Поскольку идентификаторы сравниваются по одному, а числа — численно, rc.10 оказывается выше rc.9. Имена alpha, beta и rc к тому же сортируются по алфавиту в правильном порядке, и это одна из причин, почему команды их используют. Помечайте каждого кандидата тегом в git, как описано в статье git-теги и релизы, чтобы точный коммит был записан.

Каковы критерии выхода для релиз-кандидата?

Запишите их до того, как соберёте первый RC. Рабочий набор:

• Автоматизированный набор тестов проходит на том самом коммите, из которого собрана сборка.
• Путь обновления с предыдущего релиза проверен на реалистичных данных.
• Известные проблемы разобраны, и ни одна не признана блокером.
• Производительность и доля ошибок совпадают с предыдущим релизом в пределах согласованного допуска.
• Release notes составлены и сверены с окончательным списком изменений.
• Путь отката существует, и кто-то его прочитал.

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

Что делать со сборкой, когда RC прошёл проверки?

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

Для пакетов публикуйте кандидатов в отдельном канале, чтобы обычные пользователи не получали их случайно. В npm команда npm publish --tag rc оставляет тег latest по умолчанию на прежнем месте, и кандидата получают только те, кто запросит @rc. У образов контейнеров и мобильных сборок та же идея под другими названиями: предрелизный тег, поэтапное развёртывание или канал в духе TestFlight.

Как писать release notes для релиз-кандидата?

Начинайте заметки с первого RC и держите их в согласии с кандидатами. Тестировщикам нужно знать, что изменилось, что проверить и что заведомо сломано, а раннее составление находит записи, которые в конце уже никто не помнит. Пометьте страницу или релиз на GitHub как предрелиз, чтобы никто не принял его за финальную версию, и перенесите готовый текст в GA-релиз при выпуске. Структура и содержание описаны в статье release notes программного обеспечения, а сторона GitHub — в статье GitHub release notes.

Нужны ли релиз-кандидаты SaaS-командам?

Командам с непрерывным деплоем они нужны редко, потому что деплой в прод и есть тест, а флаг функции управляет тем, кто видит изменение. Релиз-кандидаты оправдывают себя, когда пользователи сами устанавливают ПО и деплоем откатить нельзя: библиотеки, десктопные и мобильные приложения, продукты для самостоятельного хостинга и API с долгоживущими клиентами. Для облачного продукта, который открывает изменения постепенно, аналог — поэтапное развёртывание, и со стороны коммуникации его разбирает статья release notes для функции за флагом.

FAQ

Что означает RC в разработке ПО? RC — это release candidate, релиз-кандидат. Так называют сборку, которую команда намерена выпустить финальной версией, если тестирование не найдёт блокирующую ошибку. Она идёт после стадий альфа и бета и перед общей доступностью.

Достаточно ли стабилен релиз-кандидат для продакшена? Обычно да для проверки в staging или в ограниченном продакшене, но у него есть риск, которого нет у финального релиза, потому что тестирование может быть не закончено. Относитесь к нему как к коду продакшен-качества, который ещё на испытательном сроке.

Сколько релиз-кандидатов должно быть у релиза? Столько, сколько потребуется, и большинству релизов хватает от одного до трёх. Длинная череда кандидатов обычно означает, что заморозку объявили слишком рано или что покрытие тестами ловит проблемы поздно.

Может ли релиз-кандидат стать финальным релизом без изменений? Да, и это предполагаемый исход. Финальный релиз должен быть той же сборкой, что и последний кандидат, только переименованной или перемеченной как GA.

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

По теме на changeloop: Документация для разработчиков, Шаблон релиз-нот