Однажды в пятницу вечером наш пайплайн честно горел зелёным, а прод при этом лежал. Я до сих пор помню это ощущение: все галочки на месте, а пользователи пишут, что ничего не работает. Разбираться пришлось прямо в проде, потому что откат тоже не спасал.
Оказалось, что виноват был не код, а сам пайплайн. У нас был шаг, который запускал интеграционные тесты, но из-за хитрой логики с || true в bash-скрипте любой сбой этого шага молча превращался в успех. Кто-то полгода назад добавил этот костыль, чтобы «временно» не блокировать релизы, пока чинили флаки-тест. Временное, как обычно, стало постоянным.
С тех пор я вывел для себя простое правило: пайплайн должен падать громко и падать рано. Никаких || true, никаких проглоченных кодов возврата. Если шаг ничего не проверяет по-настоящему — он не имеет права быть зелёным. Зелёный статус — это обещание, и оно должно быть честным.
Мы переписали пайплайн так, чтобы каждый значимый этап явно возвращал свой exit code, а критичные проверки нельзя было пропустить флагом. Добавили отдельный обязательный gate: смоук-тест против свежесобранного образа, который реально дёргает главные ручки API. Если смоук не прошёл — артефакт даже не доезжает до регистра.
Ещё один вывод, который дался кровью: быстрый фидбэк важнее полного покрытия на каждом коммите. Мы разбили пайплайн на слои. Сначала линт и юнит-тесты — за пару минут. Потом сборка и смоук. И только в отдельной ветке — тяжёлые e2e, которые гоняются перед мержем в main, а не на каждый пуш. Инженеры перестали ждать по двадцать минут ради опечатки в импорте.
Главное, что я понял за годы работы с CI/CD: пайплайн — это не бюрократия и не галочка для менеджера. Это ваш первый и самый дешёвый пользователь, который проверяет систему раньше живых людей. Если вы врёте ему через || true, он рано или поздно ответит взаимностью и соврёт вам в самый неудачный момент. Обычно в пятницу вечером.
– Sergey Shinder
Top comments (0)