blocks|key|2037046|text|查看fabric来管理部署。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2037047|这是我用fabric来管理服务器/部署的工具：louis+(它只是fabric命令的集合)。我为每个项目都保存了一个louisconf.py文件。|style|CODE|2037048|我推荐使用分布式VCS+(git，hg，...)而不是svn。原因是分支的简单性允许部署多个方案。例如，您可以拥有production和staging分支。然后，您按照约定强制只合并到生产环境中。|2037049|至于让开发人员快速入门，您可以使用pip和requirements.txt。我认为这也意味着你正在使用virtualenv，但如果不是，那就是第三部分。我建议您准备一个基本的README。让每个加入项目的开发人员的第一个任务是更新README。|2037050|让某人加入的粗略方法是让她签出代码，创建一个virtualenv，然后安装需求。|2037051|我建议有一个与sqlite3一起工作的settings.py文件，这样新的开发人员就可以使用它来快速地进行(即在安装了需求之后)。但是，如何管理不同的设置文件取决于您的项目布局。不过，应该有一些默认设置供新开发人员使用。|2037052|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.fabfile.org/0.9.2/|1|https://github.com/rz/louis|2|http://pypi.python.org/pypi/virtualenv^0|2|6|0|0|1M|C|N|5|1|0|1L|A|1W|7|0|2F|6|37|6|1F|A|2|0|0|J|B|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|D|3|E|5|6|7|15|8|@$A|16|B|17|F|G]]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|H|3|I|5|6|7|1B|8|@$A|1C|B|1D|F|G]|$A|1E|B|1F|F|G]]|9|@]|C|$]]|$1|J|3|K|5|6|7|1G|8|@$A|1H|B|1I|F|G]|$A|1J|B|1K|F|G]]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|L|3|M|5|6|7|1O|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1P|8|@$A|1Q|B|1R|F|G]]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1S|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]|X|$5|S|T|U|C|$V|Y]]|Z|$5|S|T|U|C|$V|10]]]]

Look at <a href="http://docs.fabfile.org/0.9.2/" rel="nofollow">fabric</a> to manage deployments.

This is what I use to manage servers/deployments with fabric: <a href="https://github.com/rz/louis" rel="nofollow">louis</a> (it is just a collection of fabric commands). I keep a <code>louisconf.py</code> file with each project.

I'd recommend using a distributed VCS (git, hg,...) instead of svn. The reason being that the ease of branching allows for several schemes for deployment. You can have, for example, <code>production</code> and <code>staging</code> branches. Then you enforce that the only merges into production happen from staging by convention.

As for getting developers started quickly you have it right with pip and requirements.txt. I think that also means that you are using <a href="http://pypi.python.org/pypi/virtualenv" rel="nofollow">virtualenv</a>, but if not that's the third piece. I'd recommend getting a basic <code>README</code> in place. Have the first assignment of each developer that joins a project be to update the <code>README</code>.

The rough way to get someone on board is to have her checkout the code, create a virtualenv, and install the requirements.

I'd recommend having a <code>settings.py</code> file that works with sqlite3 and such that a new developer can use to just get going fast (ie after installing the requirements). However, how you manage the different settings files depends on your project layout. There should be some set of default settings for new developers to use, though.

blocks|key|4961526|text|我在我的主目录中保存了一个项目/目录(在Linux上)。当我需要启动一个新项目时，我会在projects/；中创建一个新的、命名简短的(充分描述该项目的)+dir，它将成为该项目的一个新的virtualenv+(带有--no-site-package)的根。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4961527|在这个目录中(在我安装venv、获取它并安装我将要使用的django副本之后)，我"django-admin.py+startproject“是一个子目录，通常使用相同的缩写。无论项目有多小，该dir都会成为我的hg代码库的根(带有一个快速的hg+init和ci)。|4961528|如果有任何机会与其他开发人员共享项目(例如，工作项目)，我会在存储库根目录中包含一个pip+requirements.txt。例如，我的开发工作流中只包含项目需求；例如，django-debug-toolbar和django-extensions不是项目需求。南方，当我们使用它的时候，就是。|4961529|至于django项目，我通常保留默认的settings.py，可能会做一些更改，并在它的末尾添加local_settings约定(try:+from+local_settings+import+*;+except+ImportError:+pass)。我和其他开发者的特定环境设置(例如，在已安装的应用程序中添加django-extensions和django-debug-toolbar+)位于local_settings.py中，而不是签入到版本控制中。为了帮助新的开发人员，您可以提供该文件的模板作为local_settings.py.temp，或者不会用于任何其他目的的其他名称，但我发现这不必要地扰乱了代码库。|offset|length|style|CODE|4961530|对于个人项目，如果我计划公开发布，我通常会包括一份自述文件。在工作中，我们维护Trac环境和良好的沟通，以使新的开发人员加快项目的进度。|4961531|至于部署，正如rz提到的，我听说fabric非常适合这种自动化的本地/远程脚本，尽管我还没有真正抓住机会去研究它。|4961532|4961533|对于外行来说，典型的shell会话可能如下所示：|4961534|$+cd+~/projects/
$+mkdir+newproj
$+cd+newproj/
$+virtualenv+--no-site-packages+.
$+source+bin/activate
(newproj)$+pip+install+django+django-debug-toolbar+django-extensions
...+installing+stuff+...
(newproj)$+django-admin.py+startproject+newproj
(newproj)$+cd+newproj/
(newproj)$+hg+init+.;+hg+ci+-A+-m+"Initial+code"|code-block|syntax|javascript|4961535|entityMap^0|0|0|0|1T|1N|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@$H|13|I|14|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|18|8|@]|9|@]|A|$]]|$1|S|3|T|5|U|7|19|8|@]|9|@]|A|$V|W]]|$1|X|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|Y|$]]

I keep a projects/ directory in my home directory (on Linux). When I need to start a new project, I make a new, shortly-named (that sufficiently describes the project) dir in projects/; that becomes the root of a new virtualenv (with --no-site-packages) for that project.

Inside that dir (after I've installed the venv, sourced it, and installed the copy of django I'll be working with), I "django-admin.py startproject" a subdir, normally by the same short name. That dir becomes the root of my hg repo (with a quick hg init and ci), no matter how small the project.

If there's any chance of sharing the project with other developers (a project for work, for example), I include a pip requirements.txt at the repo root. Only project requirements go in there; django-debug-toolbar and django-extensions, staples for my dev workflow, are not project requirements, for example. South, when we use it, is.

As for the django project, I normally keep the default settings.py, possibly with a few changes, and add the local_settings convention to the end of it (<code>try: from local_settings import *; except ImportError: pass</code>). My and other devs' specific environment settings (adding django-extensions and django-debug-toolbar to installed apps, for example) go in local_settings.py, which is not checked in to version control. To help a new dev out, you could provide a template of that file as local_settings.py.temp, or some other name that won't be used for any other purpose, but I find that this unnecessarily clutters the repo.

For personal projects, I normally include a README if I plan on releasing it publicly. At work, we maintain Trac environments and good communication to get new devs up to speed on a project.

As for deployment, as rz mentioned, I hear fabric is really good for that kind of automated local/remote scripting, though I haven't really taken the chance myself to look into it.

<hr>

For the uninitiated, a typical shell session for this might look like the following:

<pre><code>$ cd ~/projects/
$ mkdir newproj
$ cd newproj/
$ virtualenv --no-site-packages .
$ source bin/activate
(newproj)$ pip install django django-debug-toolbar django-extensions
... installing stuff ...
(newproj)$ django-admin.py startproject newproj
(newproj)$ cd newproj/
(newproj)$ hg init .; hg ci -A -m "Initial code"
</code></pre>

I'm a strong proponent of version control, and am starting work on a Django project. I've done a few before, and have tried a few different approaches, but I haven't yet found a decent structure that I actually feel comfortable with.

Here's what I want:

a) Source code checked into version control

b) Preferably the environment is not checked into version control (something like buildout or pip requirements.txt is fine for setting up the environment)

c) A reasonable "get a new developer going" story

d) A reasonable deployment story - preferably the entire deployment environment could be generated by a script on the server

It seems to me like someone has to have done this before, but many hours of searching have all led to half-baked solutions that don't really address all of these. 

Any thoughts on where I should look?

Django + SVN + Deployment

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我是版本控制的坚定支持者，并且正在着手开发一个Django项目。我以前做了一些，也尝试了一些不同的方法，但我还没有找到一个真正让我感到舒服的像样的结构。这是我想要的：a)签入版本控制的源代码b)最好不要将环境签入到版本控制中(例如buildout或pip requirements.txt可以很好地设置环境)c)一个合理...

问Django + SVN +部署
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Django + SVN +部署EN