0

The only danger I can think of is a developer using Capistrano to rollback a migration on the production database. Are there any other risks you can think of and what's the best way to avoid accidental migrations/database reset, etc?

edit: We do have daily backups in place. I would rephrase my question this way: Is there any benefit in not using migrations at all (manual schema changes only)? And do you know any Rails teams doing it?

dyanisse
  • 114
  • 1
  • 8
  • besides your daily backup - you might want to backup the db before any new deployments. - migrations are better than manual schema changes in my opinion; you can run them multiple times in dev and staging to verify they work correctly, then when you deploy you know they will get executed in the same manor. Maybe you want to limit which developers have access to deploy to production, setup a staging environment with more open access? – house9 Feb 13 '13 at 01:28

2 Answers2

2

There could be the potential for data corruption/inconsistency, especially if you are modifying existing tables.

I'd recommend that before doing any migration or rollback that you ensure you have a up to date backup and if possible run the migration on a staging environment before rolling it out to your production environment.

Tomdarkness
  • 3,800
  • 2
  • 21
  • 26
0

This is probably a more general question of what are the risks of rollbacks on a prod database. I would say that you need to make sure that if the schemas will change, make sure that existing code will not break. The best way to avoid accidental changes would probably be to back up the existing prod database. That way, you can ensure that you won't lose everything by rolling back.

TheDude
  • 3,796
  • 2
  • 28
  • 51