Closed
Bug 905361
Opened 11 years ago
Closed 9 years ago
Add alembic migrations to the stage refreshes
Categories
(Socorro :: Database, task)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: selenamarie, Assigned: selenamarie)
References
Details
I think all we need to do is add something like: . ~postgres/venv-alembic/bin/activate cd /data/socorro/application PYTHONPATH=. alembic -c ~postgres/.alembic-conf upgrade HEAD to the deploys. The caveats are: * We may need to refresh the virtualenv from time to time. We can't use the virtualenv that ships with socorro because it doesn't properly specify paths for command-line tools like alembic. * The rollbacks in our environment aren't capable of rolling back stored procedures. That's probably ok for now. It means that if we revert a commit, we will need to generate a migration for the rollback that loads the reverted stored procedures.
Assignee | ||
Comment 1•11 years ago
|
||
Tested a from-nothing setup on dev just now: virtualenv -p python2.6 venv-alembic source venv-alembic/bin/activate pip install alembic psycopg2 PYTHONPATH=. alembic -c ~/.alembic.ini upgrade head
Updated•11 years ago
|
Assignee | ||
Comment 2•11 years ago
|
||
Another consideration is how to manage downgrades/reverts. Downgrading requires that the migration be present.
Comment 3•10 years ago
|
||
Last week we discussed wrapping the db parts in either a python package or a git submodule, to make it easier to upgrade/downgrade. The crux of the problem is how we manage a release gone wrong. Currently 'push the last good release' is the response, and we manually manage downgrading the DB. Since the downgrade scripts ship with the code, rolling out the old codebase precludes the necessary downgrades. Could we get away with "downgrade the DB, then push last working release"? That way the old code is still on the box.
Assignee | ||
Comment 4•10 years ago
|
||
(In reply to Chris Lonnen :lonnen from comment #3) > Could we get away with "downgrade the DB, then push last working release"? > That way the old code is still on the box. Unfortunately, no. The trick is to get whatever database-related code *except the migration itself* reverted. Then the downgrade migration will load things like old stored procs from the source. The right way to manage this is probably a completely separate repo for migrations that is never reverted, but is shipped with releases.
Assignee | ||
Comment 5•9 years ago
|
||
Done a while ago!
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•