Good way to deploy django projecto to a testing sever?

Question

This is specific to my current project. But maybe the answers will reveal some more generic solutions.

Here is the situation:

• I develop django project on my Windows box
• I use SVN to commit to a SVN repository
• while developing I use development server that comes with django
• There is a testing server (apache) that runs somewhere else, and everytime i finish something I need to manually copy my work via WinSCP/Putty and make sure it works on testing server
• Testing server is accessible for our testers to use and test and report bugs

I would like to automate this process as it is very painful. It involves me to export the whole repository, copy to the testing server, get rid of the pyc files, sometimes restarting apache, use the correct settings.py (usually some renaming).

I would like to for the testing server to automatically retrieve new files after each SVN commit. I could write a custom script to do all this stuff, but something tells me that there are some easy-to-use solutions I could use to change my workflow to make things less painful.

One extra bonus. There is a designer that works on HTML/CSS on the templates directly on the testing server. I need to check whether he made changes and I transfer them to my computer and subsequently to SVN rep. My boss thinks it's too dangerous to give him SVN access. Any ideas to help me out with this, also?

Answer 1

One option is to create a read only svn user and have it checkout the svn repository on the apache server. Then to do a build you run 'svn update'. You can check if the designer modified files by doing a 'svn status'.

If your svn repository is on the same machine as your qa django instance you could use a post-commit hook to have it svn update after each commit, and bounce apache if needed. See http://subversion.tigris.org/faq.html#website-auto-update

Answer 2

deployment:

I would say its better to do the deployment the same way you do for the production. Fabric is a good solution.

SVN way:

If you want to do it in the SVN way, create a branch called testing, once you have a working version of your code and ready for testing merge the development branch to the testing branch. Make sure you have permission on the testing branch to restrict everyone from merging to the test branch. After merging the test team should take a update to a specific version.

.pyc

It unnecessary to manually remove pyc files you can add a svn hook which can ignore the pyc files on commit. Create a file .svnignore

*.pyc

and run this command

svn -R propset svn:ignore -F .svnignore .

If you’ve already got yourself into the mess of versioning your compiled files, then you can do either of these things.

find -name "*.pyc" -exec svn revert {} \;
find -name "*.pyc" -exec svn delete {} \;

Django settings file

You can set the environment variable through which django can take up corresponding settings file. Django set env

Designer

well designer working directly on the test server is not a bonus point. :) its a headache. In a ideal environment no one should touch the code in the testing server. Create a separate branch for the designer or he can commit to the dev branch which all the developers can merge.