Ответ
Решение о готовности к релизу принимается на основе выполнения ряда критериев, часто формализованных в чек-лист Definition of Ready (DoR) или Definition of Done (DoD).
Основные критерии:
- Успешное прохождение всех запланированных тестов.
- Unit- и интеграционные тесты.
- End-to-end (E2E) и регрессионные тесты.
- Тесты производительности и безопасности (если применимо).
- Отсутствие открытых критических (Critical/Blocker) и высокоприоритетных (High) багов. Баги среднего и низкого приоритета могут быть приняты и отложены.
- Подтверждение готовности от всех заинтересованных сторон: разработчиков, QA, продукт-менеджера, иногда DevOps.
- Готовность документации: обновлены пользовательские руководства, релизные заметки (changelog), внутренняя документация.
- Готовность инфраструктуры и плана отката (rollback plan). Продовое окружение стабильно, есть четкий и протестированный сценарий отката на предыдущую стабильную версию.
Пример формальной проверки в коде (псевдокод):
def is_release_candidate_ready(build):
criteria = {
"tests_passed": build.test_passed_rate >= 99.5,
"no_critical_bugs": build.open_critical_bugs_count == 0,
"high_priority_bugs": build.open_high_priority_bugs_count <= 2,
"docs_updated": build.docs_status == "APPROVED",
"rollback_plan_exists": True
}
return all(criteria.values())Ответ 18+ 🔞
А, ну вот, опять этот вечный вопрос — когда уже можно выкатывать фичу в прод, а? Сидим, блядь, на созвоне, все такие важные, а ответа нет. Так, слушай, я тебе сейчас по полочкам разложу, как эти умники на самом деле решают, готово или нет. Не по звёздам, блядь, гадают, а по конкретным пунктам, которые они в своих умных бумажках называют DoR или DoD. Короче, чек-лист, ёпта.
Итак, на что смотрят, прежде чем нажать большую красную кнопку:
-
Все тесты должны быть зелёными, как доллар. Это не обсуждается.
- Эти мелкие юнит-тесты, которые проверяют, не сломал ли ты одну функцию, пока чинил другую.
- Большие, жирные E2E-тесты, которые имитируют, как реальный юзер будет тыкать в интерфейс. Если они падают — всё, пиздец, иди чини.
- Ну и если проект серьёзный, то ещё и тесты на то, выдержит ли система, если на неё набегут, как тараканы, десять тысяч пользователей. И чтобы никто не взломал эту систему через какую-нибудь дыру, блядь.
-
Критических багов быть не должно, в рот меня чих-пых! Совсем. Нулевое количество. Если есть баг, из-за которого у пользователя данные теряются или всё падает — какой, нахуй, релиз? Высокоприоритетные косяки тоже желательно порешать, но парочку могут и в бэклог запихнуть, если совсем припёрло. А вот средние и мелкие — да похуй, с ними живут.
-
Все должны сказать своё жирное «ДА». Не просто кивнуть, а реально подтвердить. Разработчик говорит: «Я всё закодил». Тестировщик орёт: «Я всё проверил, работает!». Продакт бормочет: «Да, это то, что нужно бизнесу». А девопс такой хитрый: «Окей, я окружение подготовил». Если хоть один молчит или морщится — пиши пропало.
-
Бумажки тоже должны быть в порядке. А то выкатишь фичу, а там в справке написано, как было три года назад. Или в релизных заметках — одна вода. Надо, блядь, обновить всё: и что нового, и как этим пользоваться, и куда бежать, если что.
-
Инфраструктура и путь к отступлению. Это самое важное, ёбта! Продовое окружение должно быть стабильным, а не трястись, как говно в проруби. И обязательно должен быть план отката. Чёткий, протестированный сценарий, как всё быстро откатить назад, если после релиза начнётся такой пиздец, что мало не покажется. Без этого — вообще ни шагу.
Ну и для полной картины, как это выглядит в ихних умных системах (код не трогаем, он святой):
def is_release_candidate_ready(build):
criteria = {
"tests_passed": build.test_passed_rate >= 99.5,
"no_critical_bugs": build.open_critical_bugs_count == 0,
"high_priority_bugs": build.open_high_priority_bugs_count <= 2,
"docs_updated": build.docs_status == "APPROVED",
"rollback_plan_exists": True
}
return all(criteria.values())Вот и весь секрет. Если все эти пункты — True, то можно, затаив дыхание, начинать. Если хоть один False — сиди, дорогой, и допиливай. Волнение ебать, но терпения ноль.