Here at Salsify we follow a git flow branching model, so it is common for us each to work independently on feature branches while regularly merging to and from a shared develop branch. We also routinely push code to staging and production environments for internal review and release. The combination of our fast-paced development environment and extensive use of branching occasionally results in conflicts when landing new features. We recently encountered one of these conflicts (sequencing not code) in a pair of ActiveRecord migrations and found a workaround we thought might be useful to others. The following migration excerpts were written on two different branches:

Migration A:

Migration B:

Problem

Following ActiveRecord migration doc's suggestions of redefining any external models was not enough to keep us from running into a sequencing conflict. Migration B (and associated features) landed first and was subsequently pushed to our staging environment. Migration A was merged shortly after and immediately revealed an issue that was not apparent in the local dev sandbox. Migration A did not succeed because Migration B had already renamed the model's 'hierarchical' attribute. Further compounding the issue, Migration A was timestamped before Migration B. This meant that in a non-conflicted state, such as pushing this code to production, Migration A would be run first. So our fix needed to work irrespective of evaluation order. It is never recommended to modify a migration which has successfully completed, such as Migration B, so the solution came via the following updates to Migration A:

Updates to Migration A:

This simple modification provides a solution that works regardless of the order in which the migrations are evaluated. Of course, this problem could have been avoided with better communication, but it led us to a creative solution that we wouldn't of otherwise explored. We'd love to hear about any interesting solutions you've come up with when working with ActiveRecord migrations.