CI/CD for .NET with GitHub Actions: Automate Build, Test, Deploy

In modern software development, delivering features quickly and reliably is crucial. Continuous Integration and Continuous Deployment (CI/CD) pipelines automate the process of building, testing, and deploying applications. For .NET developers, GitHub Actions provides a powerful, integrated CI/CD platform directly within your repository. This tutorial will guide you through creating a production-ready CI/CD pipeline for a .NET application using GitHub Actions. You'll learn how to set up workflows that build your code, run unit and integration tests, perform security scanning, and deploy to Azure App Service. We'll cover real-world scenarios like handling secrets, caching dependencies, and conditional deployments. By the end, you'll have a robust pipeline that ensures every commit is automatically validated and deployed, reducing manual errors and speeding up your release cycle.

What is GitHub Actions and Why Use It for .NET?

GitHub Actions is a CI/CD platform that allows you to automate your build, test, and deployment pipeline directly from your GitHub repository. For .NET developers, it offers a seamless way to integrate with the .NET CLI and Azure services. You define workflows as YAML files in the .github/workflows directory. Each workflow consists of one or more jobs that run on GitHub-hosted runners (Ubuntu, Windows, macOS) or self-hosted runners. Key benefits include tight integration with GitHub, a large marketplace of pre-built actions, and generous free tier for public repositories. For .NET specifically, you can use actions like setup-dotnet to install the SDK, and azure/webapps-deploy to deploy to Azure App Service.

name: .NET CI

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: 6.0.x
    - name: Restore dependencies
      run: dotnet restore
    - name: Build
      run: dotnet build --no-restore
    - name: Test
      run: dotnet test --no-build --verbosity normal

Setting Up Your First .NET CI Pipeline

Let's create a CI pipeline that builds and tests a .NET application on every push. Start by creating a file named .github/workflows/ci.yml in your repository. The workflow will checkout the code, install the .NET SDK, restore dependencies, build, and run tests. Use the actions/checkout action to fetch your repository. The setup-dotnet action installs the specified .NET SDK version. The dotnet restore command restores NuGet packages. Then dotnet build compiles the project, and dotnet test runs unit tests. You can also add caching for NuGet packages to speed up subsequent runs.

name: CI

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: '6.0.x'
    - name: Cache NuGet packages
      uses: actions/cache@v3
      with:
        path: ~/.nuget/packages
        key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}
        restore-keys: |
          ${{ runner.os }}-nuget-
    - name: Restore dependencies
      run: dotnet restore
    - name: Build
      run: dotnet build --no-restore --configuration Release
    - name: Test
      run: dotnet test --no-build --configuration Release --verbosity normal

Adding Code Quality and Security Scanning

Beyond building and testing, you should integrate code quality checks and security scanning into your pipeline. Tools like SonarCloud, CodeQL, and .NET's built-in analyzers can catch issues early. For example, you can run dotnet format to check code style, or use the github/codeql-action to perform security analysis. Add a step to run dotnet format --verify-no-changes to enforce formatting. For security, use the CodeQL action to analyze your code for vulnerabilities. You can also integrate with Snyk or Dependabot for dependency scanning.

    - name: Check code formatting
      run: dotnet format --verify-no-changes --verbosity diagnostic
    - name: Initialize CodeQL
      uses: github/codeql-action/init@v2
      with:
        languages: csharp
    - name: Autobuild
      uses: github/codeql-action/autobuild@v2
    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v2

Deploying to Azure App Service

Once your code passes CI, you can automatically deploy to Azure App Service. The azure/webapps-deploy action simplifies this. First, create an Azure Web App and configure deployment credentials. In your GitHub repository, add the publish profile as a secret (e.g., AZURE_WEBAPP_PUBLISH_PROFILE). Then, in your workflow, add a deploy job that depends on the build job. Use the action to publish the build artifacts and deploy them. You can also use slot deployments for zero-downtime updates.

name: Deploy to Azure

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: '6.0.x'
    - name: Restore
      run: dotnet restore
    - name: Build
      run: dotnet build --configuration Release --no-restore
    - name: Publish
      run: dotnet publish --configuration Release --no-build --output ./publish
    - name: Upload artifact
      uses: actions/upload-artifact@v3
      with:
        name: webapp
        path: ./publish
  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
    - name: Download artifact
      uses: actions/download-artifact@v3
      with:
        name: webapp
    - name: Deploy to Azure Web App
      uses: azure/webapps-deploy@v2
      with:
        app-name: my-dotnet-app
        slot-name: production
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        package: .

Handling Environment-Specific Configurations

In real-world applications, you need different configurations for development, staging, and production. Use environment variables and secrets to manage these. In GitHub Actions, you can define environment-specific variables and secrets in the repository settings. Then reference them in your workflow using ${{ vars.VARIABLE_NAME }} for variables and ${{ secrets.SECRET_NAME }} for secrets. For .NET, you can use the appsettings.{Environment}.json pattern and set the ASPNETCORE_ENVIRONMENT variable in the workflow. For example, set ASPNETCORE_ENVIRONMENT: Production in the deploy job.

    - name: Deploy to Azure Web App
      uses: azure/webapps-deploy@v2
      with:
        app-name: my-dotnet-app
        slot-name: production
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        package: .
      env:
        ASPNETCORE_ENVIRONMENT: Production
        ConnectionStrings__Default: ${{ secrets.CONNECTION_STRING }}

Advanced: Matrix Builds and Conditional Steps

To test your application across multiple .NET versions or operating systems, use matrix builds. Define a matrix strategy in your job to run the same steps with different parameters. You can also add conditional steps using the 'if' keyword. For example, only run deployment on the main branch, or skip certain steps for pull requests. Matrix builds are useful for ensuring compatibility.

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        dotnet-version: ['6.0.x', '7.0.x']
    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET ${{ matrix.dotnet-version }}
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ matrix.dotnet-version }}
    - name: Restore
      run: dotnet restore
    - name: Build
      run: dotnet build --configuration Release
    - name: Test
      run: dotnet test --configuration Release --verbosity normal
    - name: Upload test results
      if: always()
      uses: actions/upload-artifact@v3
      with:
        name: test-results-${{ matrix.os }}-${{ matrix.dotnet-version }}
        path: '**/TestResults/*.trx'

Best Practices and Security Considerations

When setting up CI/CD pipelines, follow security best practices: use least privilege for service principals, rotate secrets regularly, and audit workflow runs. For GitHub Actions, avoid using self-hosted runners for public repositories unless necessary. Use OpenID Connect (OIDC) to authenticate to cloud providers instead of long-lived secrets. For .NET, enable NuGet package signing verification and use lock files. Also, consider adding a manual approval step for production deployments using GitHub Environments with required reviewers.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
    - name: Deploy
      uses: azure/webapps-deploy@v2
      with:
        app-name: my-dotnet-app
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}