CI/CD для C# проектов: GitHub Actions от А до Я

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

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

Начать курс

Введение: Зачем C# проектам CI/CD?

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

GitHub Actions — это встроенный инструмент GitHub, который позволяет создавать мощные пайплайны прямо в репозитории. В этой статье мы разберем, как настроить полноценный CI/CD для C# проектов с помощью GitHub Actions: от простой сборки до автоматического деплоя. Вы узнаете, как писать YAML-конфигурации, оптимизировать тестирование и избегать типичных ошибок.

Основы GitHub Actions для .NET

Что такое workflow и job?

Workflow (рабочий процесс) — это автоматизированный процесс, который запускается по определенному событию (push, pull request, создание релиза). Он описывается в файле .github/workflows/*.yml. Workflow состоит из одной или нескольких job (задач), которые выполняются на раннерах (виртуальных машинах). Каждая job может содержать последовательность steps (шагов).

Для C# проектов ключевые шаги — это восстановление зависимостей (dotnet restore), сборка (dotnet build), запуск тестов (dotnet test) и публикация (dotnet publish).

Базовый шаблон workflow для .NET

Ниже представлен минимальный workflow для сборки и тестирования C# проекта. Сохраните этот код в файл .github/workflows/dotnet-ci.yml.

name: .NET CI

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'

    - 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

Разбор ключевых строк:

actions/checkout@v4 — клонирует репозиторий в среду выполнения.
actions/setup-dotnet@v4 — устанавливает указанную версию .NET SDK.
dotnet restore — скачивает NuGet-пакеты.
dotnet build --configuration Release — собирает проект в режиме Release.
dotnet test — запускает все тесты из решения.

Расширенная настройка: кэширование и матрица сборки

Кэширование NuGet-пакетов

Каждый запуск workflow начинается с чистой среды. Чтобы ускорить процесс, можно кэшировать папку ~/.nuget/packages. Это особенно полезно для больших проектов с десятками зависимостей.

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

Ключ кэша строится на основе хэша файлов проектов (.csproj). Если зависимости не менялись, кэш будет восстановлен за секунды.

Матрица сборки (Matrix Strategy)

Если ваше приложение должно работать под разные версии .NET или операционные системы, используйте матрицу. GitHub Actions автоматически создаст отдельную job для каждой комбинации.

jobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        dotnet: ['6.0.x', '8.0.x']
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: ${{ matrix.dotnet }}
      - run: dotnet build --configuration Release

Этот подход гарантирует, что ваш C# код корректен на всех целевых платформах.

Автоматический деплой с GitHub Actions

Публикация артефактов

После успешной сборки и тестирования можно опубликовать результат как артефакт или сразу развернуть на сервере. Для начала создадим артефакт:

- name: Publish
  run: dotnet publish --configuration Release --output ./publish

- name: Upload artifact
  uses: actions/upload-artifact@v4
  with:
    name: my-app
    path: ./publish

Артефакты можно скачать из интерфейса GitHub Actions или использовать в последующих jobs.

Деплой на Azure или собственный сервер

Для деплоя в Azure App Service существует готовое действие azure/webapps-deploy@v2. Пример:

- name: Deploy to Azure
  uses: azure/webapps-deploy@v2
  with:
    app-name: 'my-app-service'
    slot-name: 'production'
    publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
    package: ./publish

Если вы используете собственный сервер, можно применить SSH-действие или скопировать файлы через SCP. Не забудьте сохранить чувствительные данные (пароли, ключи) в секретах GitHub.