CI/CD, Publishing & Deployment

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish

# Final, minimal runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Common follow-ups: What's the difference between the aspnet and runtime-deps base images?;How does layer caching optimize rebuild times in a multi-stage Dockerfile?

builder.Services.AddFeatureManagement();

if (await featureManager.IsEnabledAsync("NewCheckoutFlow")) {
    return NewCheckoutHandler();
} else {
    return LegacyCheckoutHandler();
}
// Code is deployed; the flag controls whether it's actually active

Common follow-ups: How do you clean up feature flags after a feature is fully rolled out?;What's the difference between release flags and permanent operational flags (like a kill switch)?

# Simplified rollback logic
- name: Monitor post-deploy
  run: |
    sleep 300  # observation window
    error_rate=$(curl -s "$METRICS_API/error_rate?window=5m")
    if (( $(echo "$error_rate > 0.05" | bc -l) )); then
      echo "Error rate too high, rolling back"
      az webapp deployment slot swap --slot staging --target-slot production --action swap
      exit 1
    fi

Common follow-ups: What metrics are most reliable signals for automated rollback decisions?;How do you avoid false-positive rollbacks from normal traffic variance?

# Framework-dependent (typical for containers, relies on base image's runtime)
FROM mcr.microsoft.com/dotnet/aspnet:8.0
COPY --from=build /app/publish .

# Self-contained (rare in containers, bundles runtime; could use a leaner base)
RUN dotnet publish -c Release -r linux-x64 --self-contained true -o /app/publish
FROM mcr.microsoft.com/dotnet/runtime-deps:8.0  # no .NET runtime at all needed

Common follow-ups: When does self-contained publishing actually help in containerized scenarios?;How does this interact with Native AOT for even smaller images?

# CI: runs on every push/PR
on: [push, pull_request]
jobs:
  build-and-test: { ... }

# CD (Continuous Deployment): auto-deploys after CI passes on main
on:
  push:
    branches: [main]
jobs:
  deploy: { needs: build-and-test, ... }

Common follow-ups: What organizational or regulatory factors push a team toward delivery over deployment?;How does feature flagging reduce the risk of full continuous deployment?

<!-- Enabling Native AOT in a .csproj is a single property -->
<PropertyGroup>
    <PublishAot>true</PublishAot>
</PropertyGroup>

# dotnet publish -r linux-x64 -c Release --self-contained
# produces a single native executable, no separate .NET runtime install needed on the target machine

Common follow-ups: What specific JSON serialization approach is compatible with Native AOT's reflection limitations?;How do you validate that a given third-party library actually supports Native AOT before adopting it?