Automatically run migrations during Heroku's "Release" Phase #1931
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ewdurbin
approved these changes
Apr 20, 2017
|
the only suggestion i'd have is documenting the requirement of backwards compatible database migrations (at least on a step by step basis) in the developer docs. similar for fastly configuration. |
Two different alembic commands attempting to run concurrency may end up fighting over who gets to apply a migration. Since we use transactions typically what will happen is that they'll both run but the later one will fail to commit the transaction and return a error code. Instead, we would like it to wait until the other command has ran and then see nothing needs to be done, and return a success code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change ensures that only one alembic command can be run at any one time (and they will queue up behind the currently running command waiting to acquire the lock). This means that two independently run migration commands won't have one of them failing to commit the transaction.
In addition this uses the Heroku Release Phase to run the database migrations and deploy the Fastly configuration automatically when a new release is created. That new release won't deploy until after the release command has been run (and if it unsuccessful, the deploy will fail).
This will prevent the Fastly config from slowing down start up as well.
One important caveat here is that obviously with an already running website both the Fastly and the DB migrations will have to not break compatibility with the currently running code unless we're fine with getting errors during that window.
Fixes #661