Как происходит развертывание приложения на текущем проекте?

Давай разберём эту вашу CI/CD магию в Azure DevOps, как есть, без соплей. Система, вроде, умная, а на деле — просто набор скриптов, которые либо делают тебе хорошо, либо разносят всё к ебеням.

Слушай сюда, вот как это у нас крутится, по косточкам:

Этап первый: Сборка (Build) — тут мы код проверяем, чтоб не хуйню собирать Первым делом, пайплайн хватает наш код и начинает его мучать. Сначала dotnet restore — подтягивает все эти ваши пакеты, эти бесчисленные зависимости, которые весят, как чугунный мост. Потом dotnet build в конфигурации Release — компилирует всё так, чтоб летало, а не плевалось исключениями.

А дальше — святое: тесты. Если тесты не прошли — всё, пиздец, дальше ни шагу. Пайплайн просто посылает тебя нахуй, и правильно делает. Вот смотри, как это в ямле выглядит, код не трогаю, он святой:

- task: DotNetCoreCLI@2
  displayName: 'Run Tests'
  inputs:
    command: 'test'
    projects: '**/*.Tests.csproj'
    arguments: '--configuration Release --collect:"XPlat Code Coverage"'

Задача DotNetCoreCLI@2 берет и гоняет все эти *.Tests.csproj. Аргумент --collect:"XPlat Code Coverage" — это чтобы потом умным видом смотреть, какой процент кода покрыт тестами. Если меньше 80% — стыдно должно быть, охренеть как стыдно.

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

Этап третий: Развертывание (Release) — тут начинается ад или триумф Вот тут уже по-разному, в зависимости от того, куда мы деплоим.

• Для веб-приложений (ASP.NET Core): Всё летит прямиком в Azure App Service. Но не просто так, а с прибабахом — слотами развертывания (staging/production). Сначала заливаем в staging, там ковыряемся, тестируем, убеждаемся, что не накосячили. Потом одним кликом — swap — и staging становится production. Если после этого всё легло — ещё один клик, и мы свапаем обратно. Откат быстрее, чем начальник успеет написать «ЧТО ПРОИСХОДИТ???». Гениально и просто.

• Для сервисов в контейнерах: Тут уже Azure Kubernetes Service (AKS). Тоже не дураки — используем blue-green деплой. Разворачиваем новую версию (green) параллельно со старой (blue). Когда green поднялся и не помер, переключаем на него весь трафик. Если что-то пошло не так — переключаем обратно на blue. Просто и без паники, как переключить канал на телевизоре.

• Для баз данных: Самое страшное. Автоматические миграции через Entity Framework Core или, что надёжнее, через DbUp. Скрипты накатываются в пайплайне, и каждый такой скрипт — это маленький инфаркт. Один неверный ALTER TABLE и можно идти писать резюме. Поэтому их проверяют дохуя раз.

А теперь про дополнительные фишки, без которых сейчас никуда:

• Feature Flags (Флаги функций): Это когда ты заливаешь новый код в продакшн, но он спит. А включаешь его только для себя, тестировщиков или 1% пользователей. Делается через Microsoft.FeatureManagement. Если фича оказалась кривой — просто выключаешь флаг, и всё, как будто её и не было. Пользователи даже не узнают, что их чуть не наебали.

• Мониторинг: После деплоя — не расслабляемся. Врубаем Application Insights и Azure Monitor. Смотрим логи, метрики, производительность. Если что-то начало тормозить или падать — узнаём об этом первыми, а не из твиттера.

• Откат (Rollback): Стратегия «нахуй-нахуй». Если всё пошло по пизде — для App Service это свап на предыдущий слот, для AKS — переключение трафика на старый под. Главное — делать это быстро, пока ущерб не превысил стоимость твоего годового оклада.

Вот и вся философия. Собрали, проверили, упаковали, залили на тест, переключили на прод, смотрим, не горит ли. Если горит — откатываем. Как по нотам. Только и всего.