Deterministic Data Seeding, Environment-Specific Data, Rollback Strategy, and Zero-Downtime Thinking

Learning outcomes

1. The practical problem: schema is correct, but the application still cannot start safely

ServiceHub may need stable reference rows—work-order priorities, system-owned tag definitions, or migration-era feature metadata—before application traffic uses a new feature. That is different from production tenant/customer data, secrets, demo fixtures, or large operational imports. “Seeding” is not one mechanism; EF Core exposes several choices with different snapshot, deployment, locking, and environment behavior.

2. Four initialization mechanisms serve different ownership models

EF documentation recommends UseSeeding/UseAsyncSeeding as the general seeding location for EF-managed initialization. Tooling invokes the synchronous seeding path in some flows, so implementing only the async delegate is an avoidable operational surprise.

3. Deterministic reference data: stable keys, no secrets

Suppose ServiceHub needs system priority definitions. Use stable keys that do not change between environments. Do not use Guid.NewGuid() inside HasData or other model-building paths; that makes every model build appear different and can trigger pending-model/migration churn.

public sealed class WorkOrderPriority{    public int Id { get; init; }    public required string Code { get; init; }    public required string DisplayName { get; init; }}// In OnModelCreating / IEntityTypeConfiguration:modelBuilder.Entity<WorkOrderPriority>(builder =>{    builder.ToTable("work_order_priorities");    builder.HasKey(x => x.Id);    builder.HasIndex(x => x.Code).IsUnique();    builder.Property(x => x.Code).HasMaxLength(24);    builder.Property(x => x.DisplayName).HasMaxLength(80);});

builder.HasData(    new WorkOrderPriority { Id = 1, Code = "normal", DisplayName = "Normal" },    new WorkOrderPriority { Id = 2, Code = "urgent", DisplayName = "Urgent" });

4. UseSeeding/UseAsyncSeeding for imperative, idempotent initialization

optionsBuilder    .UseSqlite(connectionString)    .UseSeeding((context, _) =>    {        if (!context.Set<WorkOrderPriority>().Any(x => x.Code == "normal"))        {            context.Set<WorkOrderPriority>().Add(                new WorkOrderPriority { Id = 1, Code = "normal", DisplayName = "Normal" });            context.SaveChanges();        }    })    .UseAsyncSeeding(async (context, _, ct) =>    {        if (!await context.Set<WorkOrderPriority>()                .AnyAsync(x => x.Code == "normal", ct))        {            context.Set<WorkOrderPriority>().Add(                new WorkOrderPriority { Id = 1, Code = "normal", DisplayName = "Normal" });            await context.SaveChangesAsync(ct);        }    });

The predicate is deliberately idempotent for the small lab. For multiple reference rows, use unique constraints and a robust upsert/provisioning strategy appropriate to the provider. Seeding is executed as part of EF initialization/migration operations and is protected by the migration locking mechanism; it should still be observable and bounded.

5. Deliberately wrong: random model data and production secrets in HasData

builder.HasData(new IntegrationEndpoint{    Id = Guid.NewGuid(),               // model changes on every build    Name = "production-broker",    ApiKey = "real-secret-here"        // secret committed into migration/snapshot});

This can create perpetual pending model changes and leak sensitive values into source control/migration history. Repair it by keeping the EF model deterministic and moving secrets/environment-specific resources to the deployment platform’s secret/configuration system.

6. Rollback is a business recovery plan, not “run Down and hope”

A deployment can fail because of code bugs, data incompatibility, long-running backfills, or a migration defect. Decide recovery before release:

For many production incidents, forward-fix or application rollback against a backward-compatible expanded schema is safer than immediately reversing DDL.

7. Expand/contract: make zero-downtime compatibility a sequence

Release N: EXPAND  1. Add nullable routing_code; keep dispatch_code.  2. Backfill existing rows in a measured deployment step.  3. Deploy app version that can read old/new and writes the compatibility plan.Release N+1: SWITCH  4. Make routing_code authoritative after all old writers are gone.  5. Observe missing/invalid routing_code metrics and repair stragglers.Release N+2: CONTRACT  6. Remove legacy dispatch_code reads/writes.  7. Only then drop dispatch_code in a separately reviewed migration.

Zero downtime is not guaranteed by EF. It emerges from application/schema compatibility, provider lock characteristics, data-migration duration, deployment topology, and observability. Large backfills may need chunking or a separate operational job rather than one giant migration transaction.

8. Chapter capstone lab: one deployable migration package

1. Run dotnet ef migrations has-pending-model-changes; it must be clean after intended migrations are scaffolded.
2. List migrations and record the intended source/target migration.
3. For SQLite, generate a bounded reviewed script; do not claim --idempotent support.
4. Build a migration bundle and record its SHA-256, target RID if self-contained, EF/tool/runtime versions, and config assumptions.
5. Apply to a copy of the disposable DB with the deployment identity/path.
6. Verify __EFMigrationsHistory, expected columns/indexes, deterministic seed rows, and smoke queries.
7. Run the deployment a second time and verify no duplicate seed/reference rows appear.
8. Document rollback/restore and abandoned SQLite migration-lock recovery procedures.

dotnet ef migrations has-pending-model-changes --project src/ServiceHub.EfLabdotnet ef migrations list --project src/ServiceHub.EfLabdotnet ef migrations script PreviousMigration LatestMigration   --project src/ServiceHub.EfLab   --output artifacts/servicehub-bounded.sqldotnet ef migrations bundle --project src/ServiceHub.EfLab   --output artifacts/efbundle

9. Production judgment and bridge to reverse engineering

A mature migration workflow has an owner, source-controlled migration code/snapshot, provider-specific review, CI pending-model gate, deployment artifact, restricted DDL identity, migration-state verification, locking/runbook awareness, deterministic reference-data strategy, backward-compatible rollout plan, and tested recovery. Never equate a successful database update with a safe release. Chapter 16 now reverses the direction: rather than evolving a model-first schema, it will inspect existing databases and scaffold EF models from them while preserving sustainable ownership.

Authoritative references

Use primary documentation when regenerating or adapting these deployment steps; migration behavior is provider- and version-sensitive.

• EF Core migrations overview
• Managing migrations
• Applying migrations
• EF Core .NET CLI tools
• SQLite provider limitations
• Data seeding