CI/CD для .NET: MSBuild и dotnet CLI на практике

Сборка и деплой .NET: CI/CD с MSBuild и dotnet CLI

Представьте: вы выкатываете новую версию .NET-приложения, а пайплайн падает на dotnet restore, потому что на агенте нет кэша — и приходится ждать 5 минут только загрузки зависимостей. Или вся команда ждёт, пока Jenkins соберёт legacy ASP.NET Framework через msbuild.exe на Windows-агенте, а потом вручную деплоит на IIS. Знакомая боль? Мы не раз сталкивались с такими ситуациями: и с legacy .NET Framework, и с современным .NET (начиная с 6 версии) с dotnet publish и multi-stage Docker build. Стек разный — подходы к пайплайну тоже отличаются. Мы настраиваем CI/CD под ключ для любого .NET-проекта, ускоряя релизы и сокращая ручные операции. Свяжитесь с нами — оценим ваш проект и предложим решение.

Кэширование NuGet-пакетов для разных ОС

Без кэширования dotnet restore на чистом агенте тянет зависимости заново — 2–5 минут только на restore. В GitHub Actions кеш пакетов настраивается так:

- uses: actions/cache@v4
  with:
    path: ~/.nuget/packages
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj', '**/*.props') }}
    restore-keys: |
      ${{ runner.os }}-nuget-

Для self-hosted runner на Windows путь будет %USERPROFILE%\.nuget\packages. Если не учесть это в конфиге — кеш не применится. С кэшем restore занимает секунды вместо минут. NuGet кэш — одна из ключевых оптимизаций пайплайна. Подробнее о NuGet.

Почему сборка .NET Framework требует Windows-агента?

Windows-only зависимости: COM-компоненты, Windows Registry, старые P/Invoke вызовы — такой код не соберётся на linux-агенте. Решение: либо оставить Windows-агент для сборки, либо рефакторить код (не всегда возможно). MSBuild на Windows через msbuild /p:Configuration=Release /p:Platform="Any CPU" — иногда единственный вариант. Настройка агента под любые зависимости — стандартная задача.

Миграции EF Core в CI. Типичная ошибка: миграции применяются к базе напрямую из пайплайна с dotnet ef database update без проверки на идемпотентность. При параллельных деплоях в staging два пода одновременно пытаются применить одну миграцию — race condition. Вместо этого генерируйте SQL-скрипт миграции (dotnet ef migrations script --idempotent) и применяйте через init-container или отдельный шаг с явной блокировкой. Microsoft Docs: EF Core migrations.

Подпись артефактов и публикация NuGet-пакетов. Если проект — библиотека, пайплайн должен паблишить пакет в Nexus или Azure Artifacts только при теге релиза. Нюанс: dotnet pack и dotnet nuget push требуют API key, который нельзя хардкодить. Используйте секреты GitHub или Vault, условие if: startsWith(github.ref, 'refs/tags/').

Что лучше: GitHub Actions или GitLab CI для .NET?

Оба инструмента хороши, но GitHub Actions выигрывает в интеграции с экосистемой .NET: встроенный кэш, marketplace с экшенами для SonarQube и Codecov, простой YAML. GitLab CI требует собственного runner, но даёт больше контроля над инстансами. С точки зрения затрат: GitHub Actions на публичных репозиториях бесплатен, GitLab CI — бесплатный до 400 минут в месяц. На практике мы чаще используем GitHub Actions для .NET (75% проектов), так как он требует меньше настройки.

Типовой пайплайн .NET: современный и legacy

Для современного .NET (6+) на Linux-агенте

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.x'
      - uses: actions/cache@v4
        with:
          path: ~/.nuget/packages
          key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}
      - run: dotnet restore
      - run: dotnet build --no-restore -c Release
      - run: dotnet test --no-build -c Release --collect:"XPlat Code Coverage"
      - uses: codecov/codecov-action@v4

Для .NET Framework на Windows-агенте

- name: Build run: msbuild MyApp.sln /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile 

SonarQube в пайплайне .NET. Типичная ошибка при настройке: запустить end без успешного begin из-за conditional step — анализ не загружается. Всегда оборачивайте в один job без пропуска шагов. Используйте dotnet-sonarscanner begin /k:"projectKey", затем dotnet build, затем dotnet-sonarscanner end.

Docker-образ для ASP.NET Core. Multi-stage build сокращает финальный образ с 1.5 GB до ~200 MB — в 7,5 раз меньше. Это ускоряет деплой и уменьшает поверхность атаки. Пример Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApp/MyApp.csproj", "MyApp/"]
RUN dotnet restore
COPY . .
RUN dotnet publish "MyApp/MyApp.csproj" -c Release -o /app/publish
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

В CI: docker build, scan Trivy (trivy image --exit-code 1 --severity HIGH,CRITICAL), push в registry с тегом из git sha. Microsoft рекомендует multi-stage сборки для production-образов. Microsoft Docs: .NET Docker.

Сравнение подходов к кэшированию NuGet

Что входит в работу

• Аудит текущего состояния: версия .NET, тип проекта, зависимости, среда деплоя.
• Настройка пайплайна: выбор агента, NuGet-кеш, этапы тестирования, сборки, публикации.
• Интеграция анализаторов: SonarQube, Coverlet, security-сканирование (Trivy, Snyk).
• Деплой в любую среду: IIS, Kubernetes, Azure App Service, bare metal.
• Документация: описание переменных, секретов, инструкция по добавлению новых проектов.
• Обучение команды: как пользоваться пайплайном и интерпретировать результаты.

Мы даём гарантию на стабильность пайплайна: SLO 99.9% аптайм, runbook для каждого сценария сбоя. Свяжитесь с нами для аудита вашего проекта.

Этапы работы

1. Аудит текущего состояния: версия .NET, тип проекта (веб/библиотека/сервис), существующие скрипты сборки, зависимости (Windows-only или кросс-платформа), целевая среда деплоя.
2. Проектирование пайплайна: выбор агентов, конфигурация кэша, этапы build → test → coverage → Docker build → push → deploy.
3. Реализация: написание YAML, Dockerfile, скриптов, интеграция анализаторов.
4. Тестирование: проверка на staging, тестирование параллельных деплоев, rollback.
5. Деплой на prod и документация.

Ориентиры по срокам

Закажите настройку CI/CD для .NET под ключ. Наши инженеры с многолетним опытом возьмут ваш проект от аудита до деплоя. Получите консультацию — просто напишите нам.