I just fell foul of a problem that i've encountered several times in the
past and never really thought of a good solution. I wonder if there's a
solution out there for this.
I just did some refactoring, moving Quiz#subject from being a text field
in the quizzes table to being a standalone table, so that the quizzes
table now has subject_id instead of subject. A typical bit of
There was a chain of migrations association with this, and in those
migrations were references to methods which existed at the time that the
migration was done, but were subsequently removed. So, my local
- make migrations
- run migrations
- change code
One of my colleagues then pulls down my changes, and runs the
migrations, and they blow up because the earlier ones use methods which
were there the time that *I* ran the migration, but now aren't. So, i
have to go and refactor the migrations themselves to work with the
post-migration codebase, push them up, then he pulls them down again and
runs them. I've fallen foul of this before when doing a deploy with
migrations as well.
Ways around it i can think of ...
a) i make sure that my migrations don't use something from the codebase
which is going to be deleted in the future. This seems difficult if not
(conceptually at least) impossible. When you're doing a refactor you
often have to use the old system/data to configure the new data.
b) my colleague pulls down the migrations folder before pulling down any
other folders, runs the migrations, then pulls the rest. This seems to
place unreasonable expectations on him, plus even then if he pulls
multiple commits at once (ie his code is even more out of sync with the
migrations) then it can still go wrong.
c) I break the process up into seperate commits, and some sort of clever
system runs through this sequence:
- get one commit
- run migrations (if any)
- repeat until up to date
This seems ideal but i'm not sure how to set it up.
Any opinions/advice anyone?