Как устроен процесс разработки и релизов в команде
Что проверяют
Понимание конвейера от задачи до прода в .NET-контексте и личное участие кандидата в нём. Ждут конкретных инструментов и решений, а не описания церемоний Scrum.
Как отвечать
Планирование и код. Задачи в Azure DevOps или Jira, ветка на задачу, PR с обязательным ревью и зелёной сборкой. Единый стиль через .editorconfig и анализаторы, включённые как ошибки сборки (TreatWarningsAsErrors), проверка форматирования в пайплайне. Версии пакетов фиксируются централизованно через Directory.Packages.props, чтобы проекты решения не разъехались по версиям одной библиотеки.
Тесты. Юниты на xUnit или NUnit, интеграционные через WebApplicationFactory с базой в Testcontainers. Внутренние библиотеки собираются в NuGet-пакеты и версионируются семантически, чтобы потребители обновлялись осознанно.
CI. dotnet restore, build, test, публикация артефакта или образа. Важный принцип: сборка делается один раз, дальше по окружениям едет тот же артефакт, различается только конфигурация. Пересборка под каждое окружение это способ выкатить в прод не то, что тестировали.
Конфигурация и секреты. appsettings.{Environment}.json плюс переменные окружения, секреты в Azure Key Vault или аналоге, в репозитории их нет. Локально dotnet user-secrets.
Релиз. Пайплайн с окружениями и ручным подтверждением на прод. Типовые механики:
- слоты развёртывания в Azure App Service: выкат в staging-слот, прогрев, swap, а при проблеме обратный swap как мгновенный откат;
- rolling update в Kubernetes с readiness-пробой, чтобы трафик не шёл в неподнявшийся под;
- миграции EF Core применяются отдельным шагом пайплайна, а не автоматически при старте приложения:
Database.Migrate()при нескольких репликах даёт параллельное применение и гонку. Сами миграции пишутся совместимыми с предыдущей версией кода, иначе откат приложения ломается о новую схему; - фича-флаги (Azure App Configuration, LaunchDarkly) отделяют выкат от включения функции.
Эксплуатация. Логи и трассировка через OpenTelemetry или Application Insights, алерты на рост ошибок и латентности, health-эндпоинты для оркестратора, постмортемы по инцидентам.
Полезно назвать свой вклад: сократили время сборки кэшированием пакетов, заменили ручную регрессию интеграционными тестами, вынесли миграции из старта приложения в отдельный шаг.
Где спотыкаются
Подробно рассказывают про спринты и ретро, но не могут описать, как код физически попадает на прод и как откатывается. Отдельная классика: миграции EF Core на старте приложения, что при масштабировании в несколько реплик приводит к параллельному применению и сломанной схеме.