Every environment needs seed data: reference tables, feature flags, default configurations, test accounts. When this data is managed manually, it drifts. When it drifts, staging does not match production, and bugs hide until deployment day.
The Problem
In most organizations, staging environments accumulate manual configuration entries over time. Nobody remembers why half of them exist. When a new QA environment is needed, it takes days to configure, and it still does not match staging because the documentation is outdated.
The Solution
Automating data seeding as part of the CI/CD pipeline solves this:
- Seed data lives in Git. Every reference table, every feature flag, every default configuration is a YAML file in the repository. Changes go through code review.
- Flyway handles database seeds. Flyway's repeatable migrations (R__ prefix) work well for seed data. They run on every deployment and are idempotent: they insert if missing, update if changed.
- Environment-specific overrides. A base seed file provides defaults. Environment-specific files override only what is different. Production has real API keys; staging has test keys. Same structure, different values.
The Results
When done well, new environment setup drops from days to minutes. Configuration drift disappears because every environment runs the same seed scripts. And when someone asks why a flag is set to a particular value in production, the answer is in Git history with a commit message explaining the decision.
The cultural shift is the biggest win. Engineers stop treating environment configuration as "ops work" and start treating it as code.