Azure PaaS & CI/CD — Hosting, Deploying, and Automating .NET Apps

Learning Context: Part of Phase 2 (Cloud-Native & DevOps) in the Senior .NET Engineer Learning Path 2026.

Prerequisites: NET Internals — How It All Works, EF Core & SQL Deep Dive — Change Tracker, N+1, and Performance

---

🧸 Baby Explanation: The Hotel vs Apartment Analogy

When you want to run a .NET application on the internet, you need a computer somewhere that’s always on. There are three ways to do it:

IaaS — Renting an Apartment 🏢

You get an empty room (a Virtual Machine). You must:

• Install Windows/Linux yourself
• Install .NET runtime yourself
• Apply security patches yourself
• Handle backups yourself
• Set up networking yourself

You have full control, but full responsibility.

PaaS — Staying in a Hotel 🏨

You bring your luggage (your code). The hotel handles:

• Room cleaning (OS patches)
• Security (firewalls)
• Breakfast (.NET runtime)
• Backup generator (high availability)

You just bring your code. They handle the rest.

SaaS — Eating at a Restaurant 🍽️

Everything is done for you. You just use the app (Gmail, Teams, etc.).

---

Part 1: Azure PaaS Services for .NET

Azure App Service — The Main One

This is where most .NET APIs and web apps live. It’s PaaS — you deploy your code, and Azure runs it.

What it gives you:

Feature	What It Means
Auto-scaling	If traffic spikes, Azure spins up more instances automatically
Staging slots	Deploy to “staging” first, swap to “production” with zero downtime
Custom domains	api.christianjeremia.com instead of myapp.azurewebsites.net
SSL/TLS	Free HTTPS certificate, auto-renewed
CI/CD integration	Connect to GitHub — push code, auto-deploy

How deployment works:

You push code → GitHub → Azure picks it up → Builds → Deploys to App Service

Your code goes into a folder on Azure’s servers, and a process called w3wp.exe (IIS) runs it. But you never see that — Azure handles everything.

Azure SQL Database

A managed SQL Server in the cloud. No need to:

• Install SQL Server
• Apply security patches
• Manage backups (Azure does it automatically)

Connection string looks like:

Server=mydb.database.windows.net;Database=MyDb;User Id=admin;Password=...;

Same EF Core code as your local SQL Server — just change the connection string.

Azure Service Bus

A message queue — services send messages to each other without waiting for a response.

Service A sends "OrderPlaced" → [Azure Service Bus] → Service B receives "OrderPlaced"
Service A continues working immediately       → Service B processes the order

This is what makes microservices work. You used this in your Mango project — that’s a real senior-level experience.

Azure Container Apps

The modern way to deploy microservices. You package your app as a Docker container, and Azure runs it.

Your code → Docker image → Container Registry → Azure Container Apps → Running!

No Kubernetes complexity. Azure handles scaling, load balancing, and networking.

Application Insights

Monitoring and diagnostics. It answers questions like:

• “Why is my API slow today?” 📉
• “Which endpoint is failing?” ❌
• “How many users are active?” 📊

// Add to Program.cs
builder.Services.AddApplicationInsightsTelemetry();

Then you see everything in the Azure portal — response times, failure rates, dependency calls (SQL, HTTP), and live logs.

---

Part 2: The Deployment Pipeline — From Code to Running

When you deploy a .NET app, here’s what happens step by step:

┌────────────┐     ┌──────────┐     ┌───────────┐     ┌────────────┐
│  You push  │ ──▶ │  Build   │ ──▶ │   Test    │ ──▶ │  Deploy to │
│  to GitHub │     │  .NET    │     │  xUnit    │     │  Azure     │
└────────────┘     └──────────┘     └───────────┘     └────────────┘

Step 1: Build

dotnet restore    # Download NuGet packages
dotnet build      # Compile the code

Step 2: Test

dotnet test       # Run all unit tests

If tests fail → stop deployment. Never deploy broken code.

Step 3: Publish

dotnet publish -c Release -o ./publish

This creates a folder with your compiled app and all its dependencies — ready to run.

Step 4: Deploy

Upload the published files to Azure App Service. Azure detects the new files and restarts the app.

---

Part 3: What is CI/CD?

CI — Continuous Integration

Every time you push code, the system:

1. Downloads your code
2. Restores packages
3. Builds the project
4. Runs all tests

If the build or tests fail, you get an email/Slack notification immediately. You fix it before it reaches production.

Without CI: You write code for 2 weeks, then try to build → 50 errors → panic 😱

With CI: You get errors within 5 minutes of writing them → fix immediately ✅

CD — Continuous Delivery/Deployment

After CI passes, the code is automatically deployed.

• Continuous Delivery: Code is deployed to staging automatically, but someone must click “Approve” before going to production.
• Continuous Deployment: Code goes all the way to production automatically after tests pass.

---

Part 4: GitHub Actions — How It Works

GitHub Actions is a CI/CD system built into GitHub. You define a pipeline in a YAML file.

The Anatomy of a Pipeline

name: Deploy .NET API
 
# 👇 When does this run?
on:
  push:
    branches: [main]
 
# 👇 What jobs run?
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    
    # 👇 What steps inside the job?
    steps:
      - name: Get code
        uses: actions/checkout@v3
      
      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '10.0'
      
      - name: Build
        run: dotnet build --configuration Release
      
      - name: Test
        run: dotnet test --configuration Release --no-build
      
      - name: Publish
        run: dotnet publish -c Release -o ./publish
      
      - name: Deploy to Azure
        uses: azure/webapps-deploy@v2
        with:
          app-name: my-dotnet-api
          publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}

Key Concepts

Concept	What It Is	Analogy
Trigger (on:)	What starts the pipeline	Like setting an alarm
Job	A unit of work (build, test, deploy)	Like a recipe step
Step	One command inside a job	Like an instruction in that step
Action (uses:)	Pre-built reusable step	Like a library function
Runner (runs-on:)	The VM that executes the job	Like the kitchen where you cook
Secret	Encrypted password/connection string	Like a locked safe in the kitchen

Secrets — How to Handle Passwords

Never put passwords in your code. Instead, store them in GitHub Secrets:

GitHub → Settings → Secrets and variables → Actions → New repository secret

Then use them in your pipeline:

run: dotnet run --connection-string "${{ secrets.DB_CONNECTION_STRING }}"

The value is encrypted and never appears in logs.

---

Part 5: Deployment Slots — Zero-Downtime Deployments

This is a senior-level concept. It solves the problem:

“How do I deploy new code without users seeing errors during the restart?”

Without Slots (Downtime ❌)

1. User is using the app → "Working"
2. You deploy new code → App restarts → "Error 503"
3. User sees error → "This site is broken!" 😡
4. App finishes restarting → "Working again"

With Slots (Zero Downtime ✅)

Production Slot     Staging Slot
┌────────────────┐  ┌────────────────┐
│ Old version    │  │ New version    │
│ (users here)   │  │ (nobody here)  │
│                │  │ Deploy to HERE │
│  my-api       │  │  my-api-staging│
└────────────────┘  └────────────────┘
        │                  │
        │     SWAP!        │
        ▼                  ▼
┌────────────────┐  ┌────────────────┐
│ New version    │  │ Old version    │
│ (users here)   │  │ (ready to rollback) │
└────────────────┘  └────────────────┘

The swap is instant. Users never see an error.

Bonus: If the new version has a bug, you can swap back immediately — no redeployment needed.

---

Part 6: Putting It All Together — A Real Workflow

Here’s how a professional .NET team deploys:

Developer pushes to GitHub
        │
        ▼
GitHub Action triggers
        │
        ▼
Step 1: dotnet restore + build
        │
        ▼
Step 2: dotnet test (if any fail → stop here!)
        │
        ▼
Step 3: dotnet publish
        │
        ▼
Step 4: Deploy to Azure App Service (Staging slot)
        │
        ▼
Step 5: Run smoke tests on staging URL
        │
        ▼
Step 6: Swap staging → production (zero downtime)
        │
        ▼
Done! 🚀

If anything goes wrong at Step 5: swap back to old version immediately.

---

📊 Cheat Sheet

Concept	Key Thing to Remember
PaaS	Bring code, not servers
App Service	Main .NET hosting — auto-scale, slots, HTTPS
Azure SQL	Managed SQL Server — same EF Core, different connection string
Service Bus	Message queue for microservices
CI	Build + test every push
CD	Auto-deploy after CI passes
GitHub Actions	Pipeline defined in .github/workflows/*.yml
Secrets	Passwords stored in GitHub, never in code
Deployment Slots	Staging → Swap → Prod = zero downtime
Rollback	Swap back to old slot = instant fix

---

🧪 Build Challenges

Challenge 1: Deploy POS API to Azure

This is the real one. Deploy your POS API to Azure App Service:

1. Create a free Azure account (if you don’t have one)
2. Create an App Service via the portal
3. Deploy your POS API using Git deploy or ZIP deploy
4. Verify the API works at https://your-api.azurewebsites.net

Challenge 2: Add CI/CD with GitHub Actions

1. Create .github/workflows/deploy.yml in your POS API repo
2. Add steps: build → test → publish → deploy
3. Store the publish profile as a GitHub Secret
4. Push to main and watch the pipeline run

Challenge 3: Set Up Staging and Production Slots

1. Add a staging slot to your App Service
2. Deploy new code to staging
3. Verify it works on the staging URL
4. Swap staging → production
5. Test a rollback by swapping back

Rules:

• ❌ Don’t ask Jeri for code
• ✅ Understand each concept before deploying
• ✅ Show Jeri your running Azure URL
• ✅ Show Jeri a successful GitHub Action run

---

Related:

• Senior .NET Engineer Learning Path 2026 — Phase 2: Cloud-Native & DevOps
• NET Internals — How It All Works — The apps you’ll deploy