代码之家 › 专栏 › 技术社区 › BBonifield

SVN Web开发工作流

workflow svn php

BBonifield · 技术社区 · 15 年前

我已经读过很多关于这个问题的问题,但是我实在找不到适合我们情况的好建议。我继承了这条工作流程,我正在努力改进。

我们的设置

PHP代码库(特别是Kohana)
代码库支持大约60个站点,每个站点都有唯一的模板(也就是60个QA[质量保证]域)
每个站点都有不同资产和资源的A-记录(即每个域8个A-记录)
3个开发人员
3位设计师
开发人员拥有用于本地开发的生产服务器的VMware映像
设计师不会
用于QA的共享物理开发服务器,提交后更新始终将此服务器保持在当前的主干头部
生产服务器,根据活动的功能更新为不同版本的混合和匹配

我们的工作流程

开发人员在本地工作,直到给定的特性完成,然后将整个特性提交给trunk进行内部QA。
设计师只对CSS/images/templates做一些小的修改。他们直接提交到trunk,对自己的更改进行QA,并在生产服务器上更新相应的文件,一般来说,在他们的QA之后。
当功能准备好投入使用时,生产服务器将手动更新为与该功能相关的每个文件的正确修订号。有时这很简单,有时很毛茸茸(很多 svn log 调用以查找上游依赖项)。

我们的问题

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

我所知道的

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

上游依赖关系示例

开发人员A在管理和前端都添加了一个新的幻灯片放映功能。
开发人员B在管理和前端都添加了一个新的反馈功能。
这两个特性都与位置模型/控制器逻辑交织在一起,因此会对这些关联的文件进行更改,以说明这两个新特性。
幻灯片功能进入QA,但被一些开发疏忽或范围爬行所阻碍。
反馈功能进入QA并通过,没有问题。
我们希望遵循时间线并将反馈功能推送到生产环境中,但我们不能直接这样做,因为这两个功能都需要更改位置模型/控制器。也就是说,我们不能 svn update file1 file2 file3 .
注: 这是一个简单的例子,可以通过做一些反向合并来解决这个问题。我们的问题常常比这复杂。

多站点结构信息

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

我相信还有其他人也在为类似的问题而挣扎,我希望能从你们这些聪明人的网上得到一些启示。如果我说的话像泥一样清晰,请随意提问!

2 回复 | 直到 15 年前

LLBBL 15 年前

你的工作流程可以改进,以下是我的建议:

开始使用SVN分支并定期发布构建/部署。
找出您的部署周期应该有多长,为QA留出时间。例如,如果您打算每个月发布一个构建,那么您需要3周的开发和1周的QA。3周后冻结该版本的开发,但错误修复除外。
为您的构建确定一个允许空间增长的编号方案
使用票务系统(ActiveCollab,JIRA,Mantis。。。等等)并强制执行任何提交都必须与票证关联的规则。选择一个可以使您的提交自动显示在票据中的位置。
如果要在开始开发之前开始记录您的需求,不要在票务系统中收集您的需求(看在上帝的份上)
这样做将帮助您确定给定构建中的功能。所以,用一个票号列表或每个版本的票号的一般描述来做一些发布说明。
在应用程序中嵌入内部版本号,以便可以跟踪任何给定系统上的部署。
开始使用自动化测试工具PHPUnit进行单元测试,使用Selenium进行功能测试,以加快QA,并通过降低日常更改引入新错误的可能性来提高web应用程序的质量/稳定性。
Hudson和Phing可以成为自动化构建和自动化测试的救星。

dj_segfault 15 年前

好吧,有几个想法:

对于这种工作流,使用带有流模型的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");
   }
}

使用这种技术,您可以优雅地覆盖网站仅为该客户机工作的部分方式,而为该客户机处理该功能的人员正在一个完全不同的文件中工作,这样他们就不会相互碰撞。我不确定你是否已经这样做了,这就是你所谓的“定位模型”

最后,有了这么多不同的“虚拟网站”进行测试,您将从添加自动单元测试(a la PHPUnit)和持续集成中受益匪浅,当软件工作到集成阶段时,自动启动测试。