4

I'm somewhat confused about how to implement a system based on Elastic Beanstalk that will allow me to roll back both my server code and RDS schema to a known good state in the event of a bad deploy.

I have an application that handles forward/up schema migrations on each deploy (using .ebextensions/). However, consider the following scenario:

  1. Elastic Beanstalk is running version 1 of my application and database schema.
  2. I push version 2 of my application, which migrates the RDS schema to version 2.
  3. I redeploy version 1 of my application, however, the RDS schema remains at version 2

I don't think I can roll back the migrations at step 3, because the backwards/down migration from version 2 doesn't exist at that point.

So, what is the best way to approach this? Should I be using something like capistrano in place of an Elastic Beanstalk deploy to gain more control over the process?

anthony
  • 40,424
  • 5
  • 55
  • 128

1 Answers1

2

As you surmised, there isn't a great integrated mechanism for rolling back schema changes in ElasticBeanstalk. In the event of a bad deploy, the best-case scenario is that the the schema-altering DB transactions will be rolled back automatically. In that case, you can just fix the migration that went wrong and re-push it to EB.

If you're not so lucky (e.g. running multiple migrations, and it fails halfway through), and you have to migrate your schema manually, you can:

  • Point your local application to use the RDS database (assuming you have the firewall configured to allow it), and run the migration.

(or)

  • SSH into one of your environment's EC2 instances and run the migration from there.

I'd be interested to know if there's a better automatic approach. However, when migrations fail (and you need to roll them back), you often have to fix them manually anyway.

SMX
  • 1,372
  • 15
  • 14