Hacker News Reader

Comment by bagels | Hacker News Reader

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?

View on HN

Author 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

How would you handle a situation where the underlying data needs to be transformed? For example, converting a text column to an int column?

In 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.

Reply on news.ycombinator.com