GitHub Actions + CI/CD for Beginners - Deploy Your .NET API Automatically

So far you have learned how to create a .NET API and deploy it to Azure App Service using Visual Studio Publish.

That works fine when you are learning. But in real projects, nobody wants to open Visual Studio and click Publish every single time.

This is where GitHub + CI/CD comes in.

In this post you will learn:

• What GitHub is
• What CI/CD means
• How GitHub Actions works
• How to automatically deploy your .NET API to Azure App Service whenever you push code

By the end, you will understand the modern way of shipping code.

1. What is GitHub?

GitHub is a platform where developers store their code online.

Two important terms:

• Git → the tool that tracks changes in your code (version control)
• GitHub → the website where that code lives so you can collaborate and automate things

Think of GitHub as a combination of:

• A backup for your code
• A place to work with other developers
• A platform that can automatically build and deploy your application

Main things you do on GitHub:

• Create a repository (your project)
• Push code from your computer
• Create branches
• Make Pull Requests
• Set up automation with GitHub Actions

2. What is CI/CD?

CI/CD is a way of working that removes manual steps.

CI = Continuous Integration

Every time you push code:

1. The project is built
2. Tests are run (if you have them)
3. Problems are found early

CD = Continuous Delivery / Continuous Deployment

After the code is built successfully, it can automatically:

• Be prepared for release, or
• Be deployed directly to Azure

In simple words:

You push code
     ↓
GitHub builds it
     ↓
GitHub deploys it to Azure
     ↓
Your API is updated

You no longer need to publish manually from Visual Studio.

3. How GitHub and CI/CD Work Together

GitHub has a built-in feature called GitHub Actions.

GitHub Actions is the engine that runs your CI/CD pipelines.

The flow looks like this:

Developer
   ↓
Push code to GitHub
   ↓
GitHub Actions starts
   ↓
Build the .NET project
   ↓
Deploy to Azure App Service
   ↓
API is live with the new code

This happens automatically based on rules you define.

4. Key Concepts You Need to Know

5. The Real Goal for Beginners

We want this behavior:

Every time I push code to the main branch,
GitHub should automatically build my .NET API
and deploy it to Azure App Service.

This is the most common and practical setup.

6. What You Need Before Starting

1. Your .NET 8 Web API code
2. A GitHub account
3. A repository on GitHub
4. An Azure App Service already created
5. The Publish Profile from Azure (or a better authentication method later)

7. Creating the GitHub Actions Workflow

All automation lives inside a special folder in your project:

.github/workflows/

Inside that folder you create a file, for example:

deploy.yml

Here is a simple and working example for a .NET 8 API:

name: Deploy to Azure App Service

on:
  push:
    branches:
      - main

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

    steps:
      - name: Checkout code
        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 --configuration Release --no-restore

      - name: Publish
        run: dotnet publish -c Release -o ./publish

      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v3
        with:
          app-name: 'your-app-service-name'
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          package: ./publish

8. Understanding the Workflow Step by Step

on: push
The workflow starts whenever someone pushes code to the main branch.

runs-on: ubuntu-latest
GitHub gives you a temporary Linux machine to run the steps.

Steps explained:

1. Checkout code → Downloads your repository
2. Setup .NET → Installs .NET 8 on the machine
3. Restore → Downloads NuGet packages
4. Build → Compiles the project
5. Publish → Creates the final files that will run on the server
6. Deploy → Sends those files to Azure App Service

9. How to Store Secrets Safely

Never put passwords or publish profiles directly in the YAML file.

Instead:

1. Go to your GitHub repository
2. Click Settings
3. Go to Secrets and variables → Actions
4. Click New repository secret
5. Add a secret named AZURE_WEBAPP_PUBLISH_PROFILE
6. Paste the content of your Azure Publish Profile

In the workflow you use it like this:

publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

This keeps sensitive information safe.

10. Typical Developer Flow After Setup

Once everything is configured, your daily work becomes very simple:

1. Make changes in Visual Studio
2. Commit the changes
3. Push to GitHub
4. Open the Actions tab on GitHub
5. Watch the workflow run
6. After a few minutes your API is updated on Azure

No more manual Publish button.

11. What Happens If Something Goes Wrong?

If the build fails:

• The deployment stops
• Your live website is not affected
• You can see the error in the Actions log
• You fix the code and push again

This is one of the biggest advantages of CI/CD. Problems are caught before they reach production.

12. Continuous Delivery vs Continuous Deployment

People often mix these two terms.

Continuous Delivery
The code is automatically built and ready to be deployed. A human still decides when to release it.

Continuous Deployment
The code is automatically built and deployed all the way to production without manual approval.

The example in this post is Continuous Deployment (it goes directly to Azure).

Many teams start with Continuous Delivery and add approvals later.

13. Why This Matters for .NET Developers

Before CI/CD:

• You build locally
• You click Publish
• You hope nothing breaks
• You repeat this every time

After CI/CD:

• You just push code
• GitHub builds and tests it
• Azure gets the new version automatically
• You can focus on writing features

This is how professional teams work.

14. Final Takeaway

GitHub + CI/CD changes the way you deliver software.

The simple mental model is:

Your code
   ↓
Push to GitHub
   ↓
GitHub Actions builds it
   ↓
Azure App Service receives the new version
   ↓
Your API is updated automatically

You write the code.
GitHub takes care of building and deploying it.

Once you are comfortable with this basic pipeline, you can later add:

• Unit tests
• Different environments (Dev, Staging, Production)
• Pull Request checks
• Approval gates
• Slack or Teams notifications

But for now, mastering the basic “push to main → deploy to Azure” flow is the most important step.

Happy automating!