.NET › CI/CD, Publishing & Deployment

How do you set up automated database migrations as part of a .NET CI/CD deployment pipeline safely?

Advanced

Answer

Common safe approaches include: running EF Core migrations (`dotnet ef database update`) as a separate pipeline step before deploying application code (so the schema is ready before new code that depends on it runs), using the expand-contract pattern for backward-compatible schema changes so old and new application versions can both run against the migrated schema briefly during rollout, and always taking a database backup or snapshot immediately before applying migrations in production as a safety net.

# Pipeline step: apply migrations before deploying app
- name: Apply migrations
  run: dotnet ef database update --project src/MyApp.Data --connection "$PROD_CONNECTION_STRING"

- name: Deploy application
  run: az webapp deploy --resource-group myapp-rg --name myapp --src-path ./publish.zip

Real-world example A team's deployment pipeline runs EF Core migrations as a distinct, monitored step with automatic rollback triggers, deliberately separated from the application deployment step so a failed migration halts the pipeline before any new application code goes live against a broken schema.

Common follow-ups: What's the risk of running migrations automatically on every application startup instead of as a pipeline step?;How do you handle a migration that must run against a very large table without locking it for too long?

Entity Framework Core & Data Access;Diagnostics & Performance