```mermaid theme={null}
graph LR
A[Git Commit] --> B[Pipeline Trigger]
B --> C[Build & Test]
C --> D[Deploy to Dev]
D --> E[Deploy to Staging]
E --> F{Approval}
F -->|Approved| G[Deploy to Prod]
```
***
## 5. Deployment Strategies
Choosing the right deployment strategy can be the difference between a seamless release and a production outage.
### Strategy Comparison
| Strategy | Risk | Rollback Speed | Cost | Complexity | Best For |
| ----------------- | -------- | -------------- | --------------- | ---------- | ----------------------------- |
| **Blue-Green** | Low | Instant | High (2x infra) | Low | Critical systems, databases |
| **Canary** | Very Low | Fast (minutes) | Medium | High | User-facing apps, A/B testing |
| **Rolling** | Medium | Slow (gradual) | Low | Medium | Stateless apps, microservices |
| **Feature Flags** | Minimal | Instant | Low | Medium | SaaS, gradual rollouts |
***
### Blue-Green Deployment
Deploy to an identical "green" environment while "blue" runs production. Swap traffic instantly.
#### Azure Implementation
**Using Azure App Service Deployment Slots**:
```bash theme={null}
# Deploy new version to staging slot
az webapp deployment source config-zip \
--resource-group rg-prod \
--name myapp \
--slot staging \
--src app.zip
# Warm up the staging slot
curl https://myapp-staging.azurewebsites.net/health
# Instant swap to production (zero downtime)
az webapp deployment slot swap \
--resource-group rg-prod \
--name myapp \
--slot staging \
--target-slot production
```
**Key Features**:
* **Auto-Swap**: Automatically swap after successful deployment.
* **Swap with Preview**: Test in production config before committing.
* **Instant Rollback**: If issues detected, swap back in \<5 seconds.
> \[!WARNING]
> **Gotcha: Database Migrations**
> Blue-green works great for stateless apps, but database schema changes are tricky. Both blue and green must support the current schema. Use **backward-compatible migrations** (add columns, don't drop).
**Real-World Example**: A bank deploys during business hours using blue-green. New code goes to green, runs smoke tests, then swaps. If fraud detection service fails, they swap back in 3 seconds—no customer impact.
***
### Canary Deployment
Route a small percentage of traffic (5%) to the new version. If metrics look good, gradually increase to 100%.
#### AKS with Flagger
```yaml theme={null}
# canary.yaml
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: myapp
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
service:
port: 80
analysis:
interval: 1m
threshold: 5
maxWeight: 50
stepWeight: 10
metrics:
- name: request-success-rate
thresholdRange:
min: 99
interval: 1m
- name: request-duration
thresholdRange:
max: 500
interval: 1m
```
**How It Works**:
1. Deploy new version (`myapp-v2`).
2. Flagger routes **10%** of traffic to v2.
3. Wait 1 minute, check metrics (success rate >99%, latency \<500ms).
4. If healthy, increase to 20%, then 30%, etc.
5. If metrics fail, **automatic rollback** to v1.
**Azure Front Door Weighted Routing**:
```bash theme={null}
# Add new backend pool with 10% weight
az network front-door routing-rule update \
--front-door-name myfd \
--name default-rule \
--backend-pool pool-v1 \
--backend-pool pool-v2 \
--weight-v1 90 \
--weight-v2 10
```
> \[!TIP]
> **Best Practice: Canary Metrics**
> Don't just monitor HTTP 500s. Track business metrics like "checkout completion rate" or "login success rate." A technically healthy service might still break user workflows.
***
### Rolling Deployment
Update instances one at a time. If any instance fails, stop the rollout.
#### AKS Rolling Update
```yaml theme={null}
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # Never have more than 1 pod down
maxSurge: 2 # Create 2 extra pods during update
template:
spec:
containers:
- name: app
image: myapp:v2
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
```
**How It Works**:
1. Kubernetes creates 2 new pods (v2) while 10 old pods (v1) still run.
2. Waits for new pods to pass readiness probe.
3. Terminates 1 old pod, creates 1 new pod.
4. Repeats until all 10 pods are running v2.
**Rollback**:
```bash theme={null}
# Instant rollback to previous version
kubectl rollout undo deployment/myapp
# Rollback to specific revision
kubectl rollout undo deployment/myapp --to-revision=3
```
> \[!WARNING]
> **Gotcha: PodDisruptionBudget**
> Without a PDB, Kubernetes might terminate too many pods during a node upgrade, causing an outage. Always set:
>
> ```yaml theme={null}
> apiVersion: policy/v1
> kind: PodDisruptionBudget
> metadata:
> name: myapp-pdb
> spec:
> minAvailable: 8 # Keep at least 8/10 pods running
> selector:
> matchLabels:
> app: myapp
> ```
***
### Feature Flags (Feature Toggles)
Deploy code with new features disabled. Enable features gradually via configuration.
#### Azure App Configuration + Feature Flags
```csharp theme={null}
// Startup.cs
services.AddAzureAppConfiguration(options =>
{
options
.Connect(connectionString)
.UseFeatureFlags(flags =>
{
flags.CacheExpirationInterval = TimeSpan.FromMinutes(5);
});
});
// Controller.cs
[FeatureGate("NewCheckoutFlow")]
public IActionResult Checkout()
{
return View("NewCheckout");
}
// If feature flag is OFF, this endpoint returns 404
```
**Gradual Rollout with Targeting**:
```json theme={null}
{
"id": "NewCheckoutFlow",
"enabled": true,
"conditions": {
"client_filters": [
{
"name": "Microsoft.Percentage",
"parameters": {
"Value": 20
}
},
{
"name": "Microsoft.Targeting",
"parameters": {
"Audience": {
"Users": ["user@example.com"],
"Groups": ["beta-testers"],
"DefaultRolloutPercentage": 20
}
}
}
]
}
}
```
**Rollout Plan**:
1. Enable for internal employees (100%).
2. Enable for beta users (100%).
3. Enable for 10% of general users.
4. Monitor metrics for 24 hours.
5. Increase to 50%, then 100%.
6. Remove feature flag from code after 2 weeks.
> \[!TIP]
> **Best Practice: Feature Flag Lifecycle**
> Feature flags are **temporary**. Never let them live forever. Set a TTL (time-to-live) and remove the flag once the feature is stable. Otherwise, your code becomes a graveyard of `if (featureFlag)` checks.
***
### Comparison: Real-World Scenario
**Scenario**: Deploying a payment processing service update.
| Concern | Blue-Green | Canary | Rolling | Feature Flags |
| ----------------------- | ----------------------- | ----------------- | ------------------- | ------------------------- |
| **Zero Downtime** | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| **Instant Rollback** | ✅ \<5 sec | ⚠️ 5-10 min | ❌ 10-20 min | ✅ \<1 sec |
| **Cost** | ❌ 2x infra | ⚠️ 1.2x infra | ✅ 1x infra | ✅ 1x infra |
| **Database Migrations** | ⚠️ Need backward compat | ✅ Can test schema | ❌ Risky | ✅ Isolate changes |
| **A/B Testing** | ❌ All or nothing | ✅ Gradual rollout | ❌ All or nothing | ✅ Per-user targeting |
| **Recommendation** | ❌ Too expensive | ✅ **Best choice** | ⚠️ Use with caution | ✅ **Combine with Canary** |
**Recommended Approach**: Use **Canary + Feature Flags**. Deploy code to production with the feature flag OFF. Enable the flag for 1% of users (canary), monitor for issues, then gradually roll out to 100%.
***
### Decision Flowchart
```mermaid theme={null}
graph TD
A[Need to Deploy?] -->|Yes| B{Can afford 2x infrastructure?}
B -->|Yes| C[Blue-Green]
B -->|No| D{Need fine-grained control?}
D -->|Yes, A/B testing| E[Canary + Feature Flags]
D -->|No| F{Stateless app?}
F -->|Yes| G[Rolling Update]
F -->|No| H[Blue-Green with Migration]
C --> I[Azure App Service Slots
***
## 1. Understanding CI/CD Pipelines
**What is a Pipeline?** A pipeline is a series of automated steps that take your code from source control to production. Think of it as a recipe: each step (ingredient) must complete successfully before moving to the next.
**Pipeline Stages**:
```
1. Source Control (Git)
↓
2. Build (Compile code, install dependencies)
↓
3. Test (Run unit tests, integration tests)
↓
4. Security Scan (Check for vulnerabilities)
↓
5. Package (Create deployable artifact)
↓
6. Deploy to Dev (Automatic)
↓
7. Deploy to Staging (Automatic)
↓
8. Deploy to Production (Manual approval)
```
**Why Automate?**
* **Speed**: Deploy in minutes instead of hours/days
* **Consistency**: Same process every time (no human error)
* **Quality**: Tests run automatically (catch bugs before production)
* **Traceability**: See exactly what was deployed and when
### Azure DevOps vs GitHub Actions
**Which Should You Choose?**
| Feature | Azure DevOps | GitHub Actions |
| ------------------ | --------------------------- | ------------------------- |
| **Source Control** | Azure Repos | GitHub |
| **CI/CD** | Azure Pipelines | GitHub Actions |
| **Free Tier** | 1,800 min/month | 2,000 min/month |
| **Self-Hosted** | Yes | Yes |
| **Marketplace** | Extensions | Actions Marketplace |
| **Best For** | Enterprise, Microsoft stack | Open source, GitHub-first |
\| **Best For** | Enterprise, Microsoft stack | Open source, GitHub-first |
> \[!WARNING]
> **Gotcha: Secrets in Logs**
> Never print environment variables or secrets to the console for debugging. Once a secret is in the build logs, it is compromised forever. Use **Azure Key Vault** to inject secrets at runtime without exposing them.
> \[!TIP]
> **Jargon Alert: Idempotency**
> A fancy word for "safe to run twice." Good Infrastructure as Code (IaC) is idempotent: if you deploy the same Bicep file 100 times, nothing changes after the first time. Bad scripts create 100 duplicate resources.
***
## 2. GitHub Actions: Complete Guide
**What is GitHub Actions?** GitHub Actions is a CI/CD platform built into GitHub. You define workflows (pipelines) using YAML files in your repository. When you push code, GitHub automatically runs your workflows.
**Why GitHub Actions?**
* ✅ Free for public repositories
* ✅ 2,000 free minutes/month for private repos
* ✅ Integrated with GitHub (no separate tool)
* ✅ Huge marketplace of pre-built actions
* ✅ Easy to get started
> \[!WARNING]
> **Gotcha: GitHub Actions Minutes Can Run Out**
> Free tier gives 2,000 minutes/month. If your workflows run frequently or take long, you'll hit the limit. Self-hosted runners are free (unlimited), but you manage the infrastructure. Monitor your usage in Settings → Billing.
> \[!TIP]
> **Jargon Alert: Workflow vs Action**
> **Workflow**: The entire pipeline (the YAML file). Defines when to run and what jobs to execute.
> **Action**: A reusable step (like `actions/checkout@v3`). Think of it as a pre-built function you can call. Actions are published to the GitHub Marketplace.
> \[!INFO]
> **Aside: GitHub Actions Pricing**
>
> * Public repos: Unlimited free minutes
> * Private repos: 2,000 free minutes/month, then \$0.008/minute
> * Self-hosted runners: Free (unlimited), but you pay for the VM/infrastructure
### Step-by-Step: Creating Your First GitHub Actions Workflow
Let's create a complete CI/CD pipeline from scratch:
#### Step 1: Create Workflow File
**Where?** Create `.github/workflows/` directory in your repository root.
```bash theme={null}
# Create directory structure
mkdir -p .github/workflows
# Create workflow file
touch .github/workflows/ci-cd.yml
```
**File Structure**:
```
my-repo/
├── .github/
│ └── workflows/
│ └── ci-cd.yml ← Your pipeline definition
├── src/
├── tests/
└── package.json
```
#### Step 2: Basic Workflow Structure
```yaml theme={null}
# .github/workflows/ci-cd.yml
name: CI/CD Pipeline
# When to run: On every push to main branch
# Why both push and pull_request? Push triggers deploy to staging/prod.
# Pull_request triggers build+test only (validates the PR before merge).
on:
push:
branches:
- main
pull_request:
branches:
- main
# Jobs: A workflow can have multiple jobs (run in parallel or sequence)
jobs:
build-and-test:
# ubuntu-latest is the cheapest runner (~$0.008/min for private repos).
# Only use windows-latest ($0.016/min) or macos-latest ($0.08/min)
# if your app specifically requires those operating systems.
runs-on: ubuntu-latest
# Steps: What to do
steps:
# Step 1: Checkout code (download your repository)
- name: Checkout code
uses: actions/checkout@v3
# Step 2: Setup Node.js
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
# Enabling cache here saves 30-60 seconds per build by reusing
# previously downloaded npm packages. Over hundreds of builds
# per month, this saves significant CI minutes (and money).
cache: 'npm'
# Step 3: Install dependencies
# Use 'npm ci' instead of 'npm install' in CI pipelines.
# npm ci is faster (skips dependency resolution), more reliable
# (uses exact versions from package-lock.json), and fails if
# package-lock.json is out of sync -- catching a common dev mistake.
- name: Install dependencies
run: npm ci
# Step 4: Run tests
- name: Run tests
run: npm test
# Step 5: Build application
- name: Build application
run: npm run build
```
**What Each Part Does**: