Php SVN Web开发工作流

Php SVN Web开发工作流,php,svn,workflow,Php,Svn,Workflow,我已经通读了很多关于这个问题的问题,但是我真的找不到任何适合我们情况的好建议。我继承了这个工作流程,我正在努力让它变得更好 我们的设置 PHP代码库(特别是Kohana) 代码库支持约60个站点,每个站点都有唯一的模板(即60个QA[质量保证]域) 每个站点都有不同资产和资源的A记录(即每个域8个A记录) 3开发商 3设计师 开发人员拥有用于本地开发的生产服务器的VMware映像 设计师没有 用于QA的共享物理开发服务器,提交后更新使该服务器始终处于当前主干的前端 生产服务器,根据活动的功能更

我已经通读了很多关于这个问题的问题,但是我真的找不到任何适合我们情况的好建议。我继承了这个工作流程,我正在努力让它变得更好

我们的设置

  • PHP代码库(特别是Kohana)
  • 代码库支持约60个站点,每个站点都有唯一的模板(即60个QA[质量保证]域)
  • 每个站点都有不同资产和资源的A记录(即每个域8个A记录)
  • 3开发商
  • 3设计师
  • 开发人员拥有用于本地开发的生产服务器的VMware映像
  • 设计师没有
  • 用于QA的共享物理开发服务器,提交后更新使该服务器始终处于当前主干的前端
  • 生产服务器,根据活动的功能更新为不同版本的混合匹配
我们的工作流程

  • 开发人员在本地工作,直到一个给定的特性完成,然后将整个特性提交给trunk进行内部QA
  • 设计师仅对CSS/图像/模板进行微小更改。他们直接提交到trunk,对自己的更改进行QA,并在QA之后立即更新生产服务器上的相应文件
  • 当功能准备上线时,生产服务器将手动更新为与该功能相关的每个文件的正确版本号。有时这很简单,但有时很麻烦(大量的
    svn log
    调用以查找上游依赖项)
我们的问题

  • 由于三个不同的开发人员开发不同的功能,需要不同数量的QA,我们发现自己经常遇到上游依赖性问题
  • 在任何给定的时间,我们都无法通过编程确定哪些功能在生产服务器上,哪些不在生产服务器上
    svn status-u
    将向我们显示哪些文件不是最新的,但这通常不是功能的清晰图片
我所知道的

  • 我们的一些问题可以通过设立一个生产分公司来缓解。我们至少可以监控哪些特性被添加到生产中以及何时添加,尽管这并不能解决上游依赖性问题
  • 功能分支是一种选择,我们在过去已经尝试过了。由于我们的软件每个分支需要60个QA域,因此我们遇到了流程管理问题。例如,为每个功能分支创建480个(60个域x每个域8个记录)A记录
  • 开发人员分支也是一种选择,但我们的功能QA时间各不相同。在我需要提交其他功能之前,我不能肯定地说以前的功能将退出QA
上游依赖关系示例

  • 开发者A在管理和前端都添加了一个新的幻灯片功能
  • 开发人员B在管理和前端都添加了一个新的反馈功能
  • 这两个特性都与位置模型/控制器逻辑交织在一起,因此会对这些关联文件进行更改,以考虑这两个新特性
  • 幻灯片功能进入QA,但由于开发疏忽或范围蠕变而受阻
  • 反馈功能进入QA并顺利通过
  • 我们希望遵循时间线并将反馈功能推送到生产中,但我们不能直接这样做,因为这两个功能都需要更改位置模型/控制器。也就是说,我们不能只执行
    svn更新file1 file2 file3
  • 注意:这是一个简单的示例,可以通过执行一些反向合并来解决。我们的问题往往比这更复杂
多站点结构信息

  • 我们有许多预定义的结构主题,包括视图、图像、CSS文件、JS文件等
  • 每个站点都指定了一个主题
  • 出于品牌和可扩展性的原因,每个站点都可以使用自定义视图覆盖主题视图,或者包含其他特定于站点的CSS/JS文件

我相信还有其他一些人也在为类似的问题而挣扎,我希望从你们这些互联网上的聪明人那里得到一些见解。如果我说的话看起来像泥一样清晰,请随时提问

好的,有几个想法:

对于这种工作流,使用带有流模型的SCM(如Accurev或ClearCase)会做得更好。在流模型中,工作从每个开发人员的流到集成流,再到QA流,再到发布流(或任何最有效的流)。只有准备好进入下一阶段的工作才能升级,而集成可以单独使用这些工作包来完成

正如deceze所说,您需要更模块化地分解东西,但您还需要将其与本地化系统结合起来,在该系统中,特定于客户端的功能可以覆盖代码的特定部分。我在PHP中这样做的一种方法是实现一个PHP文件导入包装器,该包装器首先查找特定于客户端的PHP文件版本,如果它不存在,则加载通用版本

function importModule($module, $clientId){
   if(is_file("${clientRootDir}/${clientId}/${module}.php")) {
      import("${clientRootDir}/${clientId}/${module}.php");
   } else {
      import("${defaultRootDir}/${module}.php");
   }
}
使用这种技术,您可以优雅地覆盖网站为该客户机工作的部分方式,而为该客户机开发该功能的人员正在一个完全不同的文件中工作,这样他们就不会相互碰撞。 我不确定你是否已经这样做了,这就是你所谓的“位置模型”


最后,有这么多不同的“虚拟网站”要测试,如果添加自动单元测试(la PHPUnit)并结合持续集成,在软件进入集成阶段时自动启动测试,您将受益匪浅。

您的工作流程可以改进,如下所示