1. Aaron Wong
  2. imp

Wiki

Clone wiki

imp / Home

For IMP developers

Note that this document refers to the IMP deployment on flipendo. It is specific to this instance, and is not a general imp deployment guide.

General development

Development should be carried out in the imp-dev instance located at

/Genomics/local/imp-dev

This instance of IMP has it's own database (the development database). It is therefore acceptable to run migrations on imp-dev. When creating migrations, insure that any delete operations on the database (removing tables, columns, etc.) are the final database changes before moving to imp-stage, and that they are not encompassed in any required migrations (i.e. adding columns, tables, etc). IMP dev is served at http://imp-dev.princeton.edu. In terms of settings, imp-dev should usually have DEBUG=True.

Moving changes to production

There are staging and production instances of IMP. These are served at http://imp.princeton.edu and http://imp-stage.princeton.edu. The code for each can be found in

/Genomics/local/imp

and

/Genomics/local/imp-stage

The 'www' directories in each of these are symlinks to either imp-dog or imp-cat. Whichever of these is pointed to by imp/www will be served at imp.princeton.edu.

To update the code running on the public imp server without downtime, go to the staging instance. Pull changes, and run any database migrations THAT DO NOT DELETE TABLES OR COLUMNS. Test this webserver through http://imp-stage.princeton.edu. When you are satisfied with the situation, change the symlink at /Genomics/local/imp/www to point to the newly updated imp code (imp-dog or imp-cat), and change the symlink at /Genomics/local/imp-stage/www to point to the other directory. Once the new code is live at http://imp.princeton.edu, database migrations can be run that delete tables or columns.

Please note that in imp-dog and imp-cat should never be deployed publicly (to http://imp.princeton.edu) with DEBUG=True set. If you do need to work on imp-stage with debug, make sure you turn it off before switching it to the production (imp) instance.

Clearing the Cache

imp-dog and imp-cat each add separate keys to the cache. This means that switching imp-stage and imp should be enough to make new templates, etc, live. Everything is cached for 24 hours (unless the cache fills up) so as long as imp-dog and imp-cat aren't switched more frequently than that, there should not be an issue. In the case that someone does wish to clear the cache, run

source imppy/bin/activate
python manage.py shell

to get a django shell. Then inside the shell run

from django.core.cache import cache
cache.clear()

Setting up virtualenv

mkdir imppy
virtualenv --no-site-packages imppy
source imppy/bin/activate

# Current hack for haystack beta
pip install -e git://github.com/toastdriven/django-haystack.git@master#egg=django-haystack

pip install -r requirements.txt


Updated