Какие инструменты и подходы CI/CD вы применяли

Что проверяют

Есть ли у вас собственный опыт сборки и выката Node.js-сервиса или вы знаете CI/CD по названиям. Интервьюеру важно, понимаете ли вы, что проверяется до мержа и как код попадает в прод. Следом часто спрашивают, как вы ускоряли медленный пайплайн или что делали с тестами, которые падают через раз.

Как отвечать

Возьмите один проект и расскажите пайплайн по шагам:

• установка: npm ci строго по lock-файлу, кэш ~/.npm или хранилища pnpm между запусками;
• статические проверки: ESLint, Prettier в режиме --check, tsc --noEmit для TypeScript;
• тесты: Jest, Vitest или встроенный node:test, интеграционные тесты с базой и Redis в сервисных контейнерах, матрица по версиям Node, если пакет публичный;
• зависимости: npm audit, Dependabot или Renovate для автоматических обновлений;
• образ: многоэтапный Dockerfile, npm ci --omit=dev в финальном слое, запуск не от root;
• выкат: GitLab CI или GitHub Actions, дальше rolling update в Kubernetes, blue-green или canary, миграции базы отдельным шагом до переключения трафика.

Покажите, что понимаете слабые места: нестабильные тесты, долгую установку зависимостей, выкат, который нельзя откатить из-за несовместимой миграции. Цифры и истории нужны свои: сколько длилась сборка, что её ускорило, какой инцидент поймал пайплайн. Если пайплайн настраивал кто-то другой, скажите об этом прямо и расскажите, какие шаги вы понимаете и что меняли сами.

Где спотыкаются

Используют npm install вместо npm ci. В CI это даёт сборку не по lock-файлу и версии зависимостей, которых не было у разработчика.

Тащат в продакшен-образ devDependencies и весь исходный каталог. Образ раздувается в разы, а вместе с ним растёт поверхность атаки.

Говорят про blue-green, но не могут объяснить, что происходит со схемой базы, когда старая и новая версии работают одновременно. Без обратно совместимых миграций такой выкат не работает.