Should we be doing a database dump before a big migration? Anything akin to rollbacks (both app or DB) possible on your end (I know it’s not available in the CLI, but perhaps there’s another avenue)?
If you run migrations as before_release commands (in .aptible.yml) and any of them fail (exit with non-zero), that’ll abort the deploy. So in clean cases where a migration fails and can roll itself back, that should work. in other cases where the migration might succeed but you still want to roll back, we do daily backups on all databases that we can roll you back to in an emergency, plus we offer a db:clone command from the CLI that creates a live clone of your database. Currently that only works with postgres-- a pg_dump and restores that into a new database. For other DB types, it takes a couple more steps.
So if you want to be really careful with a particular migration, you could clone and switch over to your clone if things are terrible.
For app rollbacks, the best option currently is just to re-deploy with the change.
OK cool, makes sense. Any equivalent to ctrl-c to kill it?
After the deploy is triggered? Not really, no. We could manually stop the deploy for you, but it’s only safe to do if it’s during the very first part of the deploy (the docker build).
Otherwise, there are API and AWS-side changes being made that are dangerous to stop mid-run.
We may be able to expose some kind of functionality like this down the road, but not yet.
We also haze heard some customer feedback regarding app rollbacks. It’s something we’re looking into.
The information here is fairly outdated. For a more current perspective, review this page: https://www.aptible.com/documentation/enclave/reference/operations.html