Environment and seed setup
How environments are promoted, how migrations run, and how starter/reference data is packaged and applied.
- Audience
- Administrators, Implementation partners
- Permissions needed
- Platform administration
- Prerequisites
- Organization setup
- Environment
- Production and staging
- Product version
- Current
- Last reviewed
- Owner
- Propulsive Product Team
Before you start
- Environment promotion moves code and schema forward; it is not a way to copy a database between environments.
Environments in a Propulsive deployment follow a defined promotion path - Development, Integration, Test, UAT/Staging and Production - and the platform treats three kinds of change differently as they move along it: schema, seed data and configuration.
Schema migrations
Database schema changes ship as numbered migration scripts, not manual edits. Migrations run in order and each one declares its own rollback (down()), so a failed release can be reverted step by step. There is no supported way to change the schema directly on the database - if it isn’t a migration, it will be overwritten by the next one.
SeedPacks
Starter and reference data ships as versioned SeedPacks rather than free-form scripts. Each pack declares:
- a stable ID and semantic version, plus an owner and a scope
- which environments it may run in (a pack targeting UAT refuses to run in Production)
- dependencies on other packs, so order is explicit rather than incidental
- a conflict policy - packs are insert-only by default, meaning an existing record is never overwritten by a re-run
- a checksum, so the manifest can prove that the pack which ran in Production is the pack that was tested
- a rollback plan and release notes
Running a pack is idempotent: running it twice creates nothing new the second time, and a deployment’s later edits to seeded rows survive a re-seed.
Configuration vs. seed data
Per-environment configuration - secrets, endpoints, API keys - stays out of seed files entirely. Seed data is the reference content both environments share; configuration is what differs between them, and the two are kept separate so a promotion never overwrites a live environment’s credentials.
What this means in practice
A fresh deployment runs migrations in order, then the packs that apply to that environment. A promotion to the next environment re-runs the same steps rather than copying the database forward - which is what keeps each environment’s own data distinct and correct.