SVN Web开发周期问题

时间:2009-11-27 15:44:05

标签: php svn

我目前工作的组织使用SVN开发PHP应用程序。我们的开发周期开始很简单,使用post-commit钩子进行提交更新Web根目录,以便立即查看更改。我们遇到的问题是开发功能妨碍了修复错误并阻止修复文件转移到生产环境,有时会导致prod服务器出现问题。

所以我介绍了一个“发布分支”模式,这意味着所有完整版本都会复制到他们自己的分支中,因此所有对生产所做的更改都需要在此分支中进行,并且“长期”开发发生在主干上。第一次启动的想法是仅修复并让开发人员负责将他们自己的更新移回主干,但是在五个开发人员实例盲目地合并导致数据丢失的变化,并且不断开发“立即释放项目”之后发布分支这种方法被放弃了。

知道我遇到了一个不同步的分支(因为有些人没有“获得”主干/分支概念并且正在主干上开发),更改从私有分支合并到主干中创建潜力在合并过去一个月从当前版本分支返回的所有更改时丢失更多代码。

我有机会重新开始并强制执行适当的Web开发/发布周期。 SVN似乎正朝着“发布”开发(二进制应用程序)的方向发展,在这种情况下,我们可以在没有将完整的软件包转移到生产的情况下整整一年。

有了这样的背景,这是我的问题: 您会针对这种情况推荐哪些Web开发SVN周期和/或架构? 这需要一个完整的方法论改革,还是我只是遗漏了一些简单的东西?

感谢您的任何想法!

5 个答案:

答案 0 :(得分:2)

我不知道你是否已经在使用这些,但我强烈推荐开发分支机构。每个新功能/错误都有自己的分支,从主干(或分支)复制,最终将其合并回来。该功能的所有开发和签到都在devel分支上进行。一旦功能/错误修复完成,然后将主干合并到开发分支FIRST中,然后在执行基本测试和验证(标准测试平台?)之后,可以将开发分支合并到主干中,知道一切都应该是在那里。

密钥是将主干合并到devel分支以获取任何新的主干更改,然后在返回合并到主干之前测试devel分支。如果每个变化都有自己的分支,那么开发人员就可以很快地完成任务。

和其他人已经提到的那样,教育工作人员。工作人员的教育没有例外,每个变更都没有例外,有自己的分支。 SVN中的副本既便宜又容易,因此没有真正的例外理由。

答案 1 :(得分:1)

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

答案 2 :(得分:1)

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

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

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

下一次发布前一周;我们创建一个发布“标签”(本质上是另一个分支)并将其发送给QA。如果此时尚未将代码合并回主干,则不会在下一个版本中使用。 (重要提示:此版本“标签”永远不会合并回主干。)因为QA发现了错误;他们被分配回开发人员。当开发人员修复它们时;他们的更改必须同时提交给发布标记和主干。

发布日来临时;我们发布该标签上的所有内容。在发布后修复的情况下;我们遵循与我们处于QA周期时相同的指导方针,如果有人在切换发布标签后将新项目合并到主干中;它不会因为紧急修复而无意中被释放。

泡沫,冲洗,重复......

这可能不会回答你的问题;但希望这可以作为您可能想要设置开发过程的良好外部观点。这不是我们原来的过程,而是我们在过去一两年里想出来的,根据我的经验,这是我们以前做过的事情的突飞猛进。

如果您对此有任何澄清;请给我留言,我会在必要时更新。

答案 3 :(得分:0)

我支持巴特;问题是培训。在项目变得太复杂而无法管理之前,您需要让您的同事正确使用SVN。你的分支方案听起来不错,但是一个不遵守计划的人确实会为其他人打破它。

再次,在您的项目变得更加复杂之前立即执行此操作。

答案 4 :(得分:0)

第一项业务是教育员工了解SVN的工作原理及其背后的方法。无论你如何优雅地制定你的计划,如果他们不能遵循它,他们就不会。

我自己在'功能'分支中做所有事情。我的布局是这样的:

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

任何触及多个文件或主要工作的内容都会在功能分支中完成。小错误修复或快速工作直接在主干。在整个开发过程中,分支机构都与主干保持同步(主干每隔几天就会合并到分支机构中)。

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

稳定完成后,它会被标记为版本,我们的构建系统现在可以根据新标记构建生产。

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