Пятница, 19:40, я нажимаю кнопку запуска пайплайна — и через двадцать минут смотрю на красный крестик в логе, чувствуя себя виноватым перед всей командой. За десять лет работы я пережил столько вечерних релизов, что могу писать мемуары под названием «Как я провёл выходные с отладчиком». И знаете что? Почти каждый раз виноват был не злой рок и не «пятница — плохой день», а одна и та же горстка типичных ошибок, которые мы сами годами таскали из проекта в проект. Давайте разберём их честно, без корпоративного глянца.
Ошибка первая — вера в то, что локальная среда равна сборочной. Я не раз слышал гордое «у меня всё работает», а потом видел, как пайплайн падает на другом образе раннера, другой версии языка и другом наборе системных библиотек. Ошибка вторая — секреты и ключи, которые живут в чьей-то голове или в личном конфиге. Ключ протух, токен отозвали, сертификат истёк в три часа ночи — и пайплайн превращается в археологические раскопки. Лечится это скучно и надёжно: пайплайн должен собираться в максимально похожем на прод окружении, а все секреты — лежать в хранилище секретов, а не в переписке.
Ошибка третья — флейки, то есть тесты, которые падают через раз. Сначала кажется мелочью, потом команда привыкает перезапускать сборку, а через месяц уже никто не смотрит на результат, потому что «оно и так иногда зелёное». Это самая опасная болезнь, потому что она убивает доверие к пайплайну. Ошибка четвёртая — отсутствие разумных таймаутов и лимитов. Если шаг может висеть бесконечно, значит однажды он повиснет именно в тот момент, когда вы уже ушли с работы и едете домой. Мой совет простой: ставьте таймауты везде, где есть сеть, и разбирайтесь с каждым флейком как с настоящим багом, а не как с досадной случайностью.
Ошибка пятая — плавающие версии зависимостей и кэш, который живёт своей жизнью. Мы обожаем удобство «поставь последнюю версию», но в ночь с четверга на пятницу эта последняя версия может оказаться чьим-то свежим сломанным релизом. Фиксируйте версии, обновляйтесь осознанно и не бойтесь время от времени чистить кэш, чтобы убедиться, что сборка работает с нуля, а не только из тёплого состояния.
Ошибка шестая — ручные шаги и знание, зашитое в одного человека. Пока деплой умеет делать только Иван, у команды нет деплоя, у команды есть Иван. Полностью автоматизированный путь до прода обязательно должен включать и обратный путь: откат, повторный залив предыдущей версии, совместимые миграции базы. Если вы не умеете откатиться за пять минут, вы не умеете деплоить. И ошибка седьмая, самая обидная — шумные уведомления и отсутствие владельца. Когда пайплайн пишет в общий чат каждый свой чих, через неделю все просто отключают звук, и падение проходит незамеченным.
Теперь про пятницу. Сама по себе она не опасна, опасна привычка ставить важный релиз в момент, когда рядом никого нет и никто не готов помочь. Поэтому у меня появились простые правила: в пятницу мы не меняем инфраструктуру и не трогаем миграции, а заливаем только то, что прошло полный прогон и уже один раз отработало в тестовой среде. Плюс я держу короткий чек-лист из пяти пунктов, по которому любой человек в команде за минуту понимает, куда смотреть при падении. Это не бюрократия, это экономия нескольких лет жизни.
Что я вынес из всего этого? Пайплайн — такой же продукт, как и само приложение. У него есть пользователи, требования, тесты и владелец. Как только к нему начинают относиться как к фону, он начинает мстить, причём исключительно неудобное время. И да, за годы практики я всё-таки полюбил CI/CD, просто перестал ждать от него магии и начал требовать предсказуемости. А какие ошибки в пайплайнах чаще всего ловите именно вы, и что помогло вашей команде сделать сборки скучными и надёжными? Делитесь опытом, люблю хорошие истории про спасённые выходные.
Ошибка первая — вера в то, что локальная среда равна сборочной. Я не раз слышал гордое «у меня всё работает», а потом видел, как пайплайн падает на другом образе раннера, другой версии языка и другом наборе системных библиотек. Ошибка вторая — секреты и ключи, которые живут в чьей-то голове или в личном конфиге. Ключ протух, токен отозвали, сертификат истёк в три часа ночи — и пайплайн превращается в археологические раскопки. Лечится это скучно и надёжно: пайплайн должен собираться в максимально похожем на прод окружении, а все секреты — лежать в хранилище секретов, а не в переписке.
Ошибка третья — флейки, то есть тесты, которые падают через раз. Сначала кажется мелочью, потом команда привыкает перезапускать сборку, а через месяц уже никто не смотрит на результат, потому что «оно и так иногда зелёное». Это самая опасная болезнь, потому что она убивает доверие к пайплайну. Ошибка четвёртая — отсутствие разумных таймаутов и лимитов. Если шаг может висеть бесконечно, значит однажды он повиснет именно в тот момент, когда вы уже ушли с работы и едете домой. Мой совет простой: ставьте таймауты везде, где есть сеть, и разбирайтесь с каждым флейком как с настоящим багом, а не как с досадной случайностью.
Ошибка пятая — плавающие версии зависимостей и кэш, который живёт своей жизнью. Мы обожаем удобство «поставь последнюю версию», но в ночь с четверга на пятницу эта последняя версия может оказаться чьим-то свежим сломанным релизом. Фиксируйте версии, обновляйтесь осознанно и не бойтесь время от времени чистить кэш, чтобы убедиться, что сборка работает с нуля, а не только из тёплого состояния.
Ошибка шестая — ручные шаги и знание, зашитое в одного человека. Пока деплой умеет делать только Иван, у команды нет деплоя, у команды есть Иван. Полностью автоматизированный путь до прода обязательно должен включать и обратный путь: откат, повторный залив предыдущей версии, совместимые миграции базы. Если вы не умеете откатиться за пять минут, вы не умеете деплоить. И ошибка седьмая, самая обидная — шумные уведомления и отсутствие владельца. Когда пайплайн пишет в общий чат каждый свой чих, через неделю все просто отключают звук, и падение проходит незамеченным.
Теперь про пятницу. Сама по себе она не опасна, опасна привычка ставить важный релиз в момент, когда рядом никого нет и никто не готов помочь. Поэтому у меня появились простые правила: в пятницу мы не меняем инфраструктуру и не трогаем миграции, а заливаем только то, что прошло полный прогон и уже один раз отработало в тестовой среде. Плюс я держу короткий чек-лист из пяти пунктов, по которому любой человек в команде за минуту понимает, куда смотреть при падении. Это не бюрократия, это экономия нескольких лет жизни.
Что я вынес из всего этого? Пайплайн — такой же продукт, как и само приложение. У него есть пользователи, требования, тесты и владелец. Как только к нему начинают относиться как к фону, он начинает мстить, причём исключительно неудобное время. И да, за годы практики я всё-таки полюбил CI/CD, просто перестал ждать от него магии и начал требовать предсказуемости. А какие ошибки в пайплайнах чаще всего ловите именно вы, и что помогло вашей команде сделать сборки скучными и надёжными? Делитесь опытом, люблю хорошие истории про спасённые выходные.