CI/CD для C# (.NET) проектов с GitHub Actions: пошаговое руководство

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Введение: Почему CI/CD критически важен для C# (.NET) проектов

Современная разработка программного обеспечения невозможна без автоматизации. Ручные процессы сборки, тестирования и развертывания — это не только медленно, но и чревато ошибками. Для C# разработчиков, работающих с экосистемой .NET, внедрение практик CI/CD (Continuous Integration / Continuous Deployment) становится стандартом индустрии.

GitHub Actions — это мощный и гибкий инструмент для автоматизации рабочих процессов, встроенный прямо в GitHub. Он позволяет создавать пайплайны (workflows), которые реагируют на события в репозитории: пуши, создание Pull Request'ов, релизы и многое другое. В этой статье мы разберем, как настроить полноценный CI/CD пайплайн для C# проекта на базе .NET, используя GitHub Actions.

Вы узнаете, как:

Настроить автоматическую сборку проекта.
Запускать unit-тесты (например, xUnit или NUnit).
Публиковать артефакты сборки.
Автоматически деплоить приложение (например, на Azure, Docker Hub или сервер).

1. Основы GitHub Actions: Workflow, Jobs и Steps

Прежде чем писать код, давайте разберемся с базовыми концепциями GitHub Actions.

Workflow (Рабочий процесс): Это автоматизированный процесс, который вы определяете в YAML-файле в папке .github/workflows. Workflow запускается по триггеру (например, push в ветку main).
Job (Задача): Набор шагов (steps), которые выполняются на одном раннере (виртуальной машине). Jobs могут выполняться последовательно или параллельно.
Step (Шаг): Отдельная команда или действие (action). Это может быть запуск скрипта, установка зависимостей или использование готового action из маркетплейса.
Runner (Раннер): Сервер, который выполняет ваш workflow. GitHub предоставляет бесплатные раннеры (Ubuntu, Windows, macOS), или вы можете запустить свой собственный.

Для .NET проектов мы будем использовать готовые actions, такие как actions/checkout (для клонирования репозитория) и actions/setup-dotnet (для установки .NET SDK).

2. Настройка базового CI пайплайна: Сборка и тестирование

Создадим наш первый workflow. Для этого в корне репозитория создайте папку .github/workflows и внутри нее файл dotnet-build.yml.

Вот минимальный YAML-файл для сборки и тестирования C# проекта:

name: .NET Build and Test

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: '8.0.x' # Укажите вашу версию .NET

    - name: Restore dependencies
      run: dotnet restore

    - name: Build
      run: dotnet build --no-restore --configuration Release

    - name: Run tests
      run: dotnet test --no-build --configuration Release --verbosity normal

Разберем код:

name: Имя workflow, которое будет отображаться в GitHub.
on: Определяет триггеры. В нашем случае — push и pull request в ветки main и develop.
jobs: Содержит одну задачу build-and-test, которая выполняется на ubuntu-latest.
steps: Последовательность действий: клонирование кода, установка .NET 8.0, восстановление пакетов NuGet, сборка в конфигурации Release и запуск тестов.

После пуша этого файла в репозиторий, GitHub Actions автоматически запустит workflow. Вы увидите зеленую галочку или красный крест рядом с коммитом.

Добавление Code Coverage (покрытие кода)

Чтобы следить за качеством кода, можно добавить генерацию отчета о покрытии тестами. Для этого используйте пакет coverlet.collector и action codecov/codecov-action.

    - name: Run tests with coverage
      run: dotnet test --no-build --configuration Release /p:CollectCoverage=true /p:CoverletOutputFormat=opencover

    - name: Upload coverage to Codecov
      uses: codecov/codecov-action@v3
      with:
        files: ./**/coverage.opencover.xml
        flags: unittests
        fail_ci_if_error: true

3. Продвинутый CD: Публикация и деплой артефактов

После успешной сборки и тестирования, следующий шаг — автоматическая публикация (деплой) приложения. Рассмотрим два популярных сценария: публикация в GitHub Packages (NuGet) и деплой на Docker Hub.

3.1. Публикация NuGet пакета в GitHub Packages

Если вы разрабатываете библиотеку, вы можете автоматически публиковать ее в GitHub Packages при создании релиза.

name: Publish NuGet Package

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
    - uses: actions/checkout@v4

    - name: Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: '8.0.x'

    - name: Build
      run: dotnet build --configuration Release

    - name: Pack
      run: dotnet pack --configuration Release --no-build --output ./nupkg

    - name: Push to GitHub Packages
      run: dotnet nuget push ./nupkg/*.nupkg --source "https://nuget.pkg.github.com/${{ github.repository_owner }}" --api-key ${{ secrets.GITHUB_TOKEN }} --skip-duplicate

Важно: Мы используем секрет secrets.GITHUB_TOKEN, который автоматически создается GitHub для каждого workflow. Он дает права на запись в Packages.