Как происходит релиз

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

Работали ли вы в команде с настроенной поставкой и понимаете ли, что происходит с вашим кодом после мержа. Типичный следующий вопрос: что вы делаете, если релиз сломал прод, и как откатываете миграцию базы.

Как отвечать

Рассказывайте процесс своей команды, а не идеальный из статьи. Каркас для .NET-проекта:

• ветки и версия: trunk-based или GitFlow, версия по SemVer из git-тега, её часто вычисляют GitVersion или MinVer;
• сборка на CI: на каждый пулреквест dotnet build, dotnet test, анализаторы и dotnet format --verify-no-changes. Пайплайн живёт в GitHub Actions, GitLab CI, Azure DevOps или TeamCity;
• артефакт: dotnet publish собирает один раз, дальше один и тот же Docker-образ едет на stage и в прод. Пересборка под каждое окружение рождает «на тесте работало»;
• миграции EF Core: не Database.Migrate() при старте нескольких инстансов, а отдельный шаг: dotnet ef migrations bundle или скрипт dotnet ef migrations script --idempotent. Схему меняют обратно совместимо, чтобы старая версия приложения пережила новую базу;
• выкатка: rolling update или canary, приложение отдаёт состояние через MapHealthChecks, недоделанные фичи прячутся за флагами Microsoft.FeatureManagement;
• после релиза: метрики, логи Serilog или OpenTelemetry, дежурный, заранее понятный критерий отката.

Если релизил отдельный человек или DevOps, так и скажите и объясните, какую часть делали сами: писали миграции, готовили release notes, проверяли прод после выкладки.

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

Отвечают «нажимаем кнопку в Jenkins» и не могут объяснить, что эта кнопка делает.

Считают, что откат это просто прошлый образ. Если миграция уже удалила колонку, прошлая версия сервиса упадёт, поэтому откат планируют вместе со схемой.

Не упоминают проверку после выкладки. Релиз заканчивается не на зелёном пайплайне, а когда ошибки и задержки вернулись к норме.