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.
从那时起，您可以使用 Fabric 将更改部署到生产服务器。
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 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.
When Apache starts, mod_wsgi starts.
When mod_wsgi starts, it reads the .wsgi files to determine what to do.
The .wsgi file -- essentially -- defines the Django request-reply handling loop that will invoke your application.
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.
Put your application code into /opt/myapp/myapp-x.y/ directory structures. The myapp-x.y name matches a git tag name.
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.
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.
发布评论
评论（2）
我建议您查看 lincoln Loop 中记录的过程。您可以直接访问他们的 github 存储库 django-startproject。基本上，django-startproject 创建的工作流程将开发、测试和生产分开。 运行开发服务器
您使用
manage.py runserver 0.0.0.0:8000 --settings=.conf.dev.settings ，并使用
manage.py test -- 执行测试 -- settings=.conf.test.settings django-startproject 将为 pip 安装一个要求文件，该文件允许您指定并轻松安装必要的依赖项。我强烈建议将 virtualenv 与 django-startproject 结合使用。可以找到有关在 Django 中使用 virtualenv 的好教程 这里。
django-startproject 还包含一个准系统 Fabric.py 脚本，可帮助在远程/云服务器上进行部署。
当然，以上所有内容都将受到 svn/hg/git/whatever 的源代码控制。
因此，在简单的 ubuntu/debian 服务器上的部署过程将是：
从那时起，您可以使用 Fabric 将更改部署到生产服务器。
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.settingsand you execute tests with
manage.py test --settings=<Project>.conf.test.settingsdjango-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:
From then on, you can use fabric to deploy changes to your production server.
这在某些情况下很容易，在某些情况下很困难。
当你改变Django中的数据库设计时，你必须重做syncdb，并且当你这样做时你可能必须提取并重新加载现有数据。这很难。有些人使用
南。我们手动完成，因为south处理大多数情况，而不是全部。当您发布新代码（没有数据库更改）时，升级非常简单。
mod_wsgi启动。mod_wsgi启动时，它会读取.wsgi文件以确定要执行的操作。.wsgi文件本质上定义了将调用您的应用程序的 Django 请求-答复处理循环。.wsgi文件的时间戳发生更改时，mod_wsgi会重新读取该文件。实际上，这将重新启动您的应用程序。这很容易。
将您的应用程序代码放入
/opt/myapp/myapp-xy/目录结构中。myapp-xy名称与 git 标签名称匹配。暂存只是使用应用程序的下一版本的 Django 配置。
/opt/myapp/myapp-2.3/。生产是当前版本。/opt/myapp/myapp-2.2/。是的，有旧版本。使用 Apache
现在，两个版本都在并行“位置”运行。
您可以通过（也许）重做数据库并更改
.wsgi文件以指向应用程序的新版本来调整暂存。您可以通过（也许）重做数据库并更改
.wsgi文件以指向应用程序的新版本来调整生产。当你有可发布的东西时，给它贴上标签。修复 Python
setup.py和setup.cfg以部署到下一个/opt/myapp/myapp-tag目录。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 becausesouthhandles most of the cases, not all of them.When you release new code (no database change) the upgrades are quite trivial.
mod_wsgistarts.mod_wsgistarts, it reads the.wsgifiles to determine what to do..wsgifile -- essentially -- defines the Django request-reply handling loop that will invoke your application..wsgifile's timestamp changes,mod_wsgirereads the file. This will, in effect, restart your application.This is pretty easy.
Put your application code into
/opt/myapp/myapp-x.y/directory structures. Themyapp-x.yname matches a git tag name.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.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
.wsgifile to point at a new release of your application.You can tweak production by (perhaps) redoing the database, and changing the
.wsgifile to point at the new release of your application.When you have something releasable, tag it. Fix your Python
setup.pyandsetup.cfgto deploy to the next/opt/myapp/myapp-tagdirectory.