Какие инструменты и подходы CI/CD вы применяли
Что проверяют
Что вы настраивали руками, а не что стояло в компании. Разница между «у нас был Jenkins» и «я собрал пайплайн и вот его этапы» видна на втором уточняющем вопросе. Дальше обычно спрашивают про самое болезненное: как выкатываете миграции базы, как откатываете неудачный релиз и где лежат секреты.
Как отвечать
Ведите рассказ по этапам своего пайплайна, с конкретикой:
- сборка и проверки:
dotnet restoreс кэшем NuGet,dotnet build -c Release,dotnet testс покрытием через--collect:"XPlat Code Coverage", включённые анализаторы иTreatWarningsAsErrors, форматирование черезdotnet format --verify-no-changes; - упаковка: многоступенчатый Dockerfile, сборка на образе
mcr.microsoft.com/dotnet/sdk:10.0, рантайм наaspnet:10.0, тег образа по хэшу коммита, пуш в реестр; - версионирование: MinVer или GitVersion от git-тегов, чтобы версия артефакта однозначно указывала на коммит;
- выкатка: окружения dev, stage, prod с ручным подтверждением на прод, стратегия rolling, blue-green или canary, фича-флаги, чтобы выключать функцию без релиза;
- база:
dotnet ef migrations bundleили идемпотентный SQL-скрипт отдельным шагом, только обратно совместимые изменения по схеме expand and contract, иначе откат приложения оставит вас с новой схемой; - секреты: переменные окружения из хранилища CI, Key Vault или Vault, ничего в репозитории и ничего в логах.
Назовите инструменты, с которыми работали (GitHub Actions, GitLab CI, Azure Pipelines, TeamCity, Jenkins), и добавьте цифры: сколько идёт пайплайн, как часто релизите, сколько времени занимает откат. Цифры отличают опыт от пересказа.
Где спотыкаются
Перечисляют названия инструментов, но не могут сказать, что именно настраивали сами и какую проблему это решало.
Забывают про базу данных. Пайплайн, который катит код и не думает про схему, разваливается на первом же откате.
Не имеют ответа на вопрос «что делает команда, когда сборка красная». Пайплайн, который все привыкли игнорировать, ценности не создаёт, и интервьюер это проверяет.