django release management (staging, testing and production) [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

开发者_运维知识库

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

I've been into django for some time now and most my focus has been around learning how to develop and run applications locally on my development machine. Now I am trying to learn best practices for deployment and release management.

I am trying now to setup my code in github and then somehow setup a production and staging environment where I can push the changes with minimum impact.

Are there best practices out there I could follow? and how do you create an agile environment whereby you can commit your code into a staging environment where customers can view the work as you do it.

---

I would recommend checking out the process as documented in lincoln loop. You can go straight to their github repo at django-startproject. Basically, the workflow that django-startproject creates segregates dev, test, and production. You run the dev server with

manage.py runserver 0.0.0.0:8000 --settings=<Project>.conf.dev.settings

and you execute tests with

manage.py test --settings=<Project>.conf.test.settings

django-startproject will install a requirements file for pip that will allow you to specify and easily install the necessary dependencies. I strongly recommend using virtualenv in combination with django-startproject. A good tutorial on using virtualenv with Django can be found here.

django-startproject also includes a barebones fabric.py script that helps deployment on remote/cloud servers.

Of course all of the above will be under source code control with svn/hg/git/whatever.

So the deployment process on a bare-bones ubuntu/debian server would be:

sudo apt-get install python-setuptools python-dev build-essential
sudo easy_install -U pip
sudo pip install -U virtualenv
mkdir -p <path>/python-environments
cd <path>/python-environments
# Create the virtual env
virtualenv --no-site-packages --distribute <my project dir>
cd <my project dir>
git clone https://github.com/<my project>.git
cd <my project>
# Install dependencies
pip install -r requirements.pip
# Run tests, setup apache, etc.

From then on, you can use fabric to deploy changes to your production server.

---

setup a production and staging environment where I can push the changes with minimum impact.

This is easy in some cases and hard in some cases.

When you change the database design in Django, you must redo syncdb, and you may have to extract and reload existing data when you do this. This is hard. Some folks use south. We did it by hand because south handles most of the cases, not all of them.

When you release new code (no database change) the upgrades are quite trivial.

1. When Apache starts, mod_wsgi starts.
2. When mod_wsgi starts, it reads the .wsgi files to determine what to do.
3. The .wsgi file -- essentially -- defines the Django request-reply handling loop that will invoke your application.
4. When a .wsgi file's timestamp changes, mod_wsgi rereads the file. This will, in effect, restart your application.

how do you create an agile environment whereby you can commit your code into a staging environment where customers can view the work as you do it.

This is pretty easy.

1. Put your application code into /opt/myapp/myapp-x.y/ directory structures. The myapp-x.y name matches a git tag name.

2. Staging is simply a Django configuration using the next release of the app. /opt/myapp/myapp-2.3/. Production is the current release. /opt/myapp/myapp-2.2/. Yes, there are older releases.

3. Define your Apache configuration to have two (or more) "locations", using the Apache <Location> directive. One location is "production" with ordinary paths. The other is "staging" with other paths. Or use virtual host. Or any other Apache thing that makes you happy.

Now you have both versions running in parallel "locations".

You can tweak staging by (perhaps) redoing the database, and changing the .wsgi file to point at a new release of your application.

You can tweak production by (perhaps) redoing the database, and changing the .wsgi file to point at the new release of your application.

When you have something releasable, tag it. Fix your Python setup.py and setup.cfg to deploy to the next /opt/myapp/myapp-tag directory.