3. A test that the migrations will deploy. I'd like to check that you can run the migrations from main/trunk and then run the local migrations and you don't get hash conflicts or anything like that.

re: 3

This is why you build migrations, put in VCs, then execute in QA/staging before prod. You reset QA/staging from prod regularly to test.

let's you ensure the same scripts run in each environment.

Not sure what you mean by hash conflict. like to know more.

I'm looking for much faster feedback than that. I want to find out that I've been an idiot and mutated a deployed changeset when I try and commit it, long before I try and deploy it to an environment.

I'm still not sure I completely understand, nor do I necessarily think Twitter makes for a good convo.

Mutating changesets isn't something

really allows. We hash your changeset, and if you alter it, then you need a repair.

However, 1/

Chronology in db changes can really matter. It's one reason why db dev is maddening compared with app.

If I alter a changeset, I need to a) reset a test env and b) redeploy.

I also need to know if this has been deployed to prod. If so, I never, ever, ever (repeat) 2/

change the changeset. Doing so invalidates how I would undo or fix a live db.

I would roll forward, so I'd need a new changeset. Really, as a dev, I need insight into whether something has left dev and made it to ops.

3/

If you need backwards compatibility, there are a few things with unit tests that should help catch issues. If ne parameters appear, they have to include defaults. If new columns appear, same.

This doesn't test logic, just API compat 4/