5 ms·
So how would you deal with continuous deployment to test but less frequent deployment to production? In test you might make multiple sequential schema changes b
by bagels 8y ago
So how would you deal with continuous deployment to test but less frequent deployment to production? In test you might make multiple sequential schema changes before deploying to production. Don't you just end up in the same place as with migrations?
How about multiple engineers making schema changes simultaneously?
How is a diff really much different from a migration?
- djrobstep 8y agoAuthor here. Where I've used this in a CI environment, the migration step goes from: - check schema version number, if newer version exists, apply migration files to: - check schema on this branch matches production schema exactly, if it doesn't, look for (one or more) pending migration files that would bring production to target state, apply those files So you can still have multiple migration files as needed. The differences: - no version numbers - no long migration chain (you can clean up old pending files once they've hit prod) - migrations are tested directly, and only get applied if a correct outcome will result
- fbonetti 8y agoHow would you handle a situation where the underlying data needs to be transformed? For example, converting a text column to an int column?
- djrobstep 8y agoIn that particular example, migra will detect that change and generate the right `alter column` statement with a `using` clause. It's impossible to handle every case, of course, such as when renames happen or data needs to be moved/inserted. Migration scripts always need reviewing. Tools can get you most of the way there automatically, and help you test, but not all of the way.