2

我们的部署策略：我们有环境范围的数据库配置和.htaccess文件（想想prod.htaccess，dev.htaccess和local.htaccess）。部署是使用 capistrano 完成的，它首先检查要部署的分支，然后删除Capfile和超出范围的.htaccess文件，并将范围内的 htaccess 从重命名[env].htaccess为.htaccess. 完成后，repository/public_html目录通过非删除 rsync 传输到 apache webroot。

背景：我工作的公司是一家在线出版物，自 1998 年以来一直存在，部署策略很复杂，因为文件夹结构一团糟：版本控制的文件位于生成的文件和用户上传的文件旁边。在这种情况下，我们不能将整个 apache webroot 文件夹符号链接到/current. 每次进行新部署时，生成的文件都会被清除，用户上传的分散在目录中的文件必须从其他地方符号链接，等等。因此，非删除 rsync 操作。

不过，上面提到的当前精神错乱是另一天的问题。

我想要的是一个不需要在部署时删除和重命名 repo 中的 htaccess 和 db 配置文件的解决方案。原因是我们可以工作和提交，/deploy/current而不必与部署中的本地更改纠缠不清。

部署这样的环境范围文件的典型解决方案是什么？我应该将它们移动到/config上面的文件夹/public_html并从 apache webroot 符号链接到相关文件，/config具体取决于环境？

4

1 回答 1

2

我建议您通过以下方式解决此问题：

  • 仍然将所有[env].htaccess文件保留在存储库中。
  • 将deploy:update所有[env].htaccess文件符号链接到.htaccess 符号链接后 ( ln --symbolic [env].htaccess .htaccess)
  • 不要删除*.htaccess文件。
  • 让开发人员/管理员编辑*.htaccess文件（他们将可以通过.htaccess符号链接访问范围内的文件以及所有范围外的 [env].htaccess 文件。
  • 让开发人员/系统操作员直接从deploy/current文件夹提交（但请确保它是您可以提交的有效存储库。）。
  • 将此过程用于您使用的其他类型的文件。

我认为这可能会解决您描述的问题，或者至少可以缓解它。我会亲自开始这样做，看看效果如何。

BTW 为什么要删除Capfileafter deploy:update？

于 2012-10-19T15:57:39.107 回答