2009-11-27 41 views
2

我目前工作的组织使用SVN开发PHP应用程序。我们的开发周期开始很简单,做一个提交使用post-commit钩子来更新web根目录,以便立即查看更改。比起我们遇到的一个问题,开发特性阻碍了错误修复,并阻止了固定文件被​​移动到生产环境,并且有时会导致prod服务器出现问题。SVN网页开发周期问题

所以我介绍了一个“释放分支”架构,这意味着所有的全版本都复制到自己的分公司,所以在这个分支与“长期”的发展发生生产所需的所有变化发生于躯干。第一次启动的想法是只做修复并让开发人员负责将自己的更新移回到主干,但是在开发人员盲目合并导致数据丢失的更改以及持续开发“即时发布项目”之后发布分支这种方法被放弃了。

知道我面临的是一个不同步的分支(因为有些人没有“获得”干线/分支的概念,并且正在干线上开发),其中的变化合并到来自私人分支的干线中,合并来自当前版本分支的过去一个月的所有更改时可能会丢失更多代码。

我不得不重新开始和执行Web开发的适当开发/发行周期的机会。 SVN似乎是面向“发布”开发(二进制应用程序),在这种情况下,我们可以整整一年不移动完整的软件包到生产环境。

有了这样的背景,这里是我的问题:什么 Web开发SVN周期和/或模式你会推荐这种情况呢? 这是否需要一个完整的方法学改革,或者我只是缺少一些简单的东西?

感谢您的任何想法!

回答

1

这是我们典型的开发周期;我们是“虚假敏捷”;并运行2周的发布周期。

所有项目都从树干的分支开始。没有例外。

一旦项目完成并清除代码审查,开发人员将被指示将该分支合并到主干中。那样;没有经过彻底审查的代码无法进入主干。我们使用CruiseControl进行持续集成,因此在提交到主干后,如果有任何测试失败,则开发人员负责修复它们。这些修复程序放在主干上。

一个星期前的下一个版本;我们创建一个发布“标签”(本质上是另一个分支)并将其发送给QA。如果你现在还没有将你的代码重新合并到主干中,那么下一版本就不会出现这个问题。 (重要提示:这个版本的“标签”永远不会合并回主干。)由于QA发现错误,他们被分配回开发者。当开发人员修复它们时;他们的更改必须同时发布到发布标签和中继。

当发布日到来时;我们在该标签上发布所有内容。在发布修补程序的情况下;我们遵循与我们进入质量保证周期相同的准则,这样,如果有人在释放标签被切断后将新项目合并到主干中,它不会在紧急修复中被无意中释放。

泡沫,漂洗,重复...

这可能不是回答你的问题本身;但希望这可以作为您如何设置开发流程的良好外部观点。这不是我们原来的过程,而是我们在过去一两年提出的,而且根据我的经验,这是前所未有的突破。

如果您想对此做任何澄清,只是留下评论,我会根据需要进行更新。

+0

>其更改必须同时提交到发布标签和中继。 提交标签?就个人而言,我认为最好将修复只提交给主干,并在所有问题得到解决时重新进行标记。通常,标签是某个时刻代码库状态的“只读快照”,并且不能修改。 – 2009-11-27 16:18:07

+0

您遇到的问题是,如果另一名开发人员在标签被剪切后将其项目合并到主干中,然后重新标记,则他们的项目现在处于发布阶段。 – 2009-11-27 16:23:54

+0

这可以缓解运行到“立即发布项目”和“开发功能”之间的冲突的问题,OP描述了 – 2009-11-27 16:27:21

1

这总是很困难的,无论您使用的系统。我怀疑有比以前使用的解决方案更好的解决方案。也许花更多的时间教育你的同事这个​​概念?

0

我备份巴特在此;问题在于培训。在项目过于复杂而无法管理之前,您需要让您的同事正确使用SVN。你的分支计划听起来对你的描述没有问题,但确实有一个人不遵循这个计划会让其他人分手。

再次,现在就开始做吧,然后再让您的项目变得更加复杂。

2

我不知道你是否已经在使用这些,但我强烈建议开发分支机构。每个新功能/错误都有自己的分支,它从主干(或分支)复制而出,最终被合并回去。该功能的所有开发和签入都发生在devel分支上。一旦功能/ bug修复完成后,trunk被合并到开发分支FIRST中,然后在执行了基本测试和验证(标准测试台?)之后,开发分支可以合并到主干中,并且知道所有东西都应该是在那里。

关键是将树干合并到devel分支中,以拾取任何新的树干更改,然后在返回合并到树干之前测试devel分支。如果每个变化都有自己的分支,那么开发人员就会很快地摆脱事物的摆动。

和其他人已经提到的那样,教职员工的教育。对于工作人员的教育没有例外情况,每个变更都有自己的分支也不例外。 SVN中的副本既便宜又容易,所以没有真正的例外借口。

0

业务的第一步将是教育您的员工了解SVN的工作方式及其背后的方法。无论你制定计划有多优雅,如果他们不能遵循,他们也不会。

我自己在“特色”分支中做所有事情。我的布局是这样的:

branches/ 
    [feature branches] 
    stable/ 
tags/ 
    [all of our releases] 
trunk/ 

凡是倒是多了几个文件,或重大的工作,在一个特性分支得到执行。小错误修复或快速工作直接在主干中完成。在整个开发过程中,分行都与行李箱保持同步(行李箱每隔几天合并到分行)。

当发布时间到来时,我们会将所有要发布的功能集成到主干中。一个功能分支被合并,检查,如果好,则移入稳定分支。清洗,冲洗,重复所有功能分支。

一旦稳定完成,它将被标记为发布版本,我们的构建系统现在可以基于新标记构建生产。

如果我们需要进行直接投入生产的紧急修复,标签将被检出,更正并生成补丁。该补丁应用于树干,然后馈送到Stable和任何新的功能分支。

+0

我想我会使用这个响应和Jim的组合,因为它是一个很好的模式。 感谢您花时间帮助我! 问候,罗宾 – Robin 2009-12-18 16:41:41