Phase 1: Upgrade schema for new code. Migrate initial data from old schema to new schema.
[Deploy: New code starts taking requests, writing to new schema. Old code is drained from the pool of handlers, continues to write to the old schema. Once old code is drained from the pool and the new code is validated by production traffic, run Phase 2.]
Phase 2: Catch-up migration of old data to new schema. Drop old schema.
I used Liquibase for migrations - change-sets can be tagged with contexts[1] and when you run the migration you can specify contextual information that each change-set can target (e. g. development AND pre-deployment). The principal tags I used were pre-deployment and post-deployment (which map to Phase 1 and Phase 2 above).
Schema migrations were a little harder to write but it meant that we could migrate live without impact to customers.
Phase 1: Upgrade schema for new code. Migrate initial data from old schema to new schema.
[Deploy: New code starts taking requests, writing to new schema. Old code is drained from the pool of handlers, continues to write to the old schema. Once old code is drained from the pool and the new code is validated by production traffic, run Phase 2.]
Phase 2: Catch-up migration of old data to new schema. Drop old schema.
I used Liquibase for migrations - change-sets can be tagged with contexts[1] and when you run the migration you can specify contextual information that each change-set can target (e. g. development AND pre-deployment). The principal tags I used were pre-deployment and post-deployment (which map to Phase 1 and Phase 2 above).
Schema migrations were a little harder to write but it meant that we could migrate live without impact to customers.
[1]: http://www.liquibase.org/documentation/contexts.html