Skip to main content

Employee Database Migrations and Seeding

Summary​

Employee Service contains two ordered EF Core migrations and one current model snapshot. Runtime startup applies pending migrations unless migration execution is explicitly disabled; development startup then invokes an idempotent seeder.

Audience​

  • Backend and QA engineers
  • DevOps engineers reviewing schema evolution

Migration inventory​

SequenceMigrationPurposeSource
120260701173627_InitialEmployeeSchemaCreates the Employee schema model, 13 persisted objects, child foreign keys, and initial indexesmicroservices/src/employee-service/Infrastructure/Migrations/20260701173627_InitialEmployeeSchema.cs
220260701181407_AddTimelineEventFieldsExtends timeline classification/metadata, constrains selected timeline text fields, and adds tenant/time indexingmicroservices/src/employee-service/Infrastructure/Migrations/20260701181407_AddTimelineEventFields.cs
CurrentEmployeeDbContextModelSnapshotCaptures the current EF model used for future migration diffsmicroservices/src/employee-service/Infrastructure/Migrations/EmployeeDbContextModelSnapshot.cs

Runtime and design-time behavior​

The service startup invokes database migration before mapping application endpoints. A design-time context factory exists for EF tooling with a null tenant context. Connection mechanisms and fallback values are intentionally excluded.

Development-only seeding runs after migration. It checks for existing tenant-scoped codes with explicit filter bypass, creates a small synthetic organization/Employee baseline only when missing, and saves incrementally. Seed identities and personal-looking sample values are intentionally omitted. Seeder execution outside Development is Not implemented by this startup path.

Safe migration workflow​

  • Generate migrations from reviewed model changes in a controlled development environment.
  • Review generated Up/Down operations, schema names, object ownership, indexes, constraints, and data-loss risk.
  • Validate from an empty database and from the previous supported migration in an isolated test environment.
  • Compare the resulting model with the committed snapshot.
  • Apply through the approved deployment process with backup, observation, and rollback decisions owned by operations.

No production command, direct SQL, or automatic rollback procedure is documented here. Although generated migrations contain Down methods, production rollback support and data restoration guarantees are Requires confirmation.

Backward compatibility​

The second migration is additive except for narrowing timeline field storage types to configured lengths. Compatibility with historical values should be tested before promotion. No explicit expand/contract policy or zero-downtime migration framework was found.

Source References​

  • microservices/src/employee-service/Infrastructure/Migrations/20260701173627_InitialEmployeeSchema.cs
  • microservices/src/employee-service/Infrastructure/Migrations/20260701181407_AddTimelineEventFields.cs
  • microservices/src/employee-service/Infrastructure/Migrations/EmployeeDbContextModelSnapshot.cs
  • microservices/src/employee-service/Infrastructure/DevelopmentSeeder.cs
  • microservices/src/employee-service/Infrastructure/Persistence.cs
  • microservices/src/employee-service/Program.cs

See Also​

Keywords​

  • EF Core migrations
  • Development seeding
  • Model snapshot

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-15
  • Review cycle: Quarterly