我认为您需要更多关于您部署的网站类型的信息：根据网站之间的关系，以编程方式和“合法”方式（如在商业关系中）存在差异：
如果你是一个网页设计师和程序员有几个客户，那么你可能会从分离受益 -
- 具有每“现场”的系统帐户，如果网站是“拥有”不同的人都能得心应手。
- 如果您的网站是相关的，即论坛网站，博客网站等，您可能会受益于单一部署系统（如我们的）。
- 对于图书馆来说，如果它们是在信誉良好的资源（pypy，github等）上托管的，那么它可能会将它们留在那里并从它们进行部署 - 如果它们位于宕机的主机上，并把它们放在我们的git仓库的第三方文件夹中。
FABRIC 面料是惊人的 - 如果配置适合你的设置和：
- 在这里，我们有一个政策，这意味着没有人需要登录到服务器（这是大多真的 - 有时候我们想看看原始的nginx日志文件，但它很少见）。
- 我们有布配置，以便有各个功能块（restart_nginx，restart_uwsgi等），而且其运行的所有小块以正确的顺序
- 更高级别的“生意”功能 - 为我们所有更新我们的服务器我们小心地输入'fab -i secretkey实时部署' - 实时设置活动服务器的设置，并部署ldeploys（-i是可选的，如果你有。ssh密钥设置正确）
- 我们甚至有一个控制标志，如果使用实时设置，它会在执行部署之前询问'您确定'。
我们的代码布局
所以我们的代码库的布局看起来有点像这样：因为我们我们的二进制文件加载到我们的回购，但它意味着
/ <-- folder containing readme file etc
/bin/ <-- folder containing nginx & uwsgi binaries (!)
/config/ <-- folder containing nginx config and pip list but also things like pep8 and pylint configs
/fabric/ <-- folder containing fabric deployment
/logs/ <-- holding folder that nginx logs get written into (but not committed)
/src/ <-- actual source is in here!
/thirdparty/ <-- third party libs that we didn't trust the hosting of for pip
可能有争议，如果我升级nginx，并想要回滚，我只是通过操纵git来完成。我知道什么是对什么构建有效。
我们的部署工作原理：
我们所有的源代码托管在一个私人到位桶回购（我们有很多回购和少数用户的，这就是为什么到位桶对我们来说是更好的，然后github上）。我们有一个用于'服务器'的用户帐户，它有自己的bitshcket的ssh密钥。
部署在织物执行每个服务器上的以下：
- IRC机器人宣布开始到IRC频道
- GIT中拉
- PIP部署（从一个PIP列表中我们回购）
- syncdb
- south migrate
- uwsgi restart
- 芹菜重启
- IRC bot的公布完成情况纳入IRC频道
- 开始可用性测试
- 宣布可用性测试（或后报告为民营引擎收录）
的“可用性测试”的结果（因为单位测试，但针对实时服务器） - 点击“测试”帐户上的所有网页和API，以确保其获取正常数据而不影响实时统计数据。
我们也有一个备份git的服务，所以如果到位桶下跌，它落在了该摆好，我们甚至有詹金斯整合上提交的“部署”分支，它会导致部署要经过
吓人的位
因为我们使用云计算和期待高吞吐量，我们的盒子自动重生。 Theres是一个包含git repo等副本的默认映像，但总是会过期的，所以它们是一个启动脚本，它自动部署，这意味着添加到集群的新框自动更新。
这可能会被关闭，因为这里真的有4个问题。我保持一切简单，并把我所有的网站放在'/ sites/www.mysite.com /'下。在特定站点的文件夹中，我有一个'project'文件夹，其中包含需要检入VCS的特定于该站点的* everything *文件夹，包括配置，设置，自述文件，要求等。 – 2012-04-05 10:37:58