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 під ключ. Наші інженери з багаторічним досвідом візьмуть ваш проект від аудиту до деплою. Отримайте консультацію — просто напишіть нам.