我们最近为我们的一位客户建立了一个新的开发基础设施和流程。这涉及严格使用 subversion 作为中央源代码存储库。svn 存储库包含实时系统 (/branches/live/) 上的代码的单独分支。存储库用于 PHP 内容（主要是 Wordpress 博客），但将来它们也可能包含其他 asp 代码。如果解决方案与 Windows Server 2008 R2 上的 ASP 代码大致相同，则可获得加分。
我们有两台服务器：一台临时系统和一台实时系统。临时系统会定期使用主干代码进行更新。实时系统是手动更新的。服务器上的每个 webroot 都是主干（临时系统）或实时分支（实时系统）的工作副本。
当前的工作流程是：
在开发人员的机器上开发 -> 提交到主干 -> 在暂存系统上自动部署 -> 在暂存系统上测试 -> 合并到 /branches/live/ -> 在实时系统上手动部署。
这对于单向更改非常有效，但是每次更新 wordpress（或插件）时我们都会遇到一些问题：WP 更新过程会删除目录并解压新版本的存档。这也会删除 svn 管理区域，从而产生大量错误。我们可以切换到具有单个全局管理区域的 SVN 1.7，但这只能解决部分问题。
最后，我们通过 WP Gui 进行了更新，恢复了 svn 管理区域，添加/删除了文件，并将更改提交到了主干。经过测试，我们必须在实时服务器上执行基本相同的操作（除了提交之外，我们只是恢复了更改并将新文件从暂存系统合并到实时系统）。
我目前正在考虑以下几点：
- 每个网站的 htdocs 都是 svn 导出
- 每个网站在 htdocs 目录旁边都有一个 svn 工作副本
- 一个脚本，在 WP 更新后从 htdocs “重放” wc 中的更改（将更改的文件 rsync 到工作副本，rsync 新文件和
svn add它们，最后是svn delete删除的文件）。该脚本必须排除一些文件（如 wp-config.php、uploads/temp 目录等）。
有没有更好的方法？不幸的是，由于时间和预算限制，完整的 CI 服务器超出了范围。