5 ms·
For database schema changes, here is the standard practice: - You have version 1 of the software, supporting schema A. - You deploy a version 2 supporting both
by navaati 7y ago
For database schema changes, here is the standard practice: - You have version 1 of the software, supporting schema A. - You deploy a version 2 supporting both schema A and new schema B. Both versions coexist until the deployment iis complete and all version 1 instances are stopped. During all this time the database is still on schema A, this is fine because your instances, both version 1 and 2, support schema A.
- Now you do the schema upgrade. This is fine because your instances, now all runnning version 2, support schema B
- At last, if you wish you can now deploy a version 3, dropping the support for schema A.
- rockostrich 7y agoMy company uses HBase currently for things on premise and we're moving to a mix of psql and BigTable in GCP. This is how we do things except all of our "schemas" are defined by the client so we just have to make sure that serialization/deserialization works correctly. With psql we might have to figure out a migration strategy, but for now we'll just be using it to store raw bytes.
- daigoba66 7y agoWe do it the other way (and I’ve always seen it done this way): database change is compatible with current code and new code. So deploy the database change, then deploy the code change. It usually allows you to rollback code changes.
- sciurus 7y agoThis is generally harder to pull off though unless you do things like force all DB access to go through stored procedures. And then you're really still pursuing the same strategy described above, except for your stored procedures instead of your app code.