SVN web开发周期问题答案

【问题标题】：SVN web development cycle issueSVN web开发周期问题
【发布时间】：2009-11-27 15:44:05
【问题描述】：

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

所以我引入了“发布分支”模式，这意味着所有完整版本都复制到自己的分支中，因此对生产所做的所有更改都需要在此分支中进行，而“长期”开发则在主干上进行。最初的想法是只做修复，让开发人员负责将自己的更新移回主干，但在五个开发人员盲目合并更改导致数据丢失的实例之后，以及不断开发“即时发布项目”上发布分支这种方法被放弃了。

知道我面临一个不同步的分支（因为有些人没有“理解”主干/分支的概念，而是在主干上开发），更改从私有分支合并到主干，从而创造了潜力从当前发布分支合并上个月的所有更改时丢失更多代码。

我有机会重新开始并执行适当的 Web 开发开发/发布周期。 SVN 似乎正朝着“发布”开发（二进制应用程序）的方向发展，在这种情况下，我们可以在不将整个软件包投入生产的情况下进行整整一年。

在这样的背景下，这是我的问题：对于这种情况，您会推荐什么 Web 开发 SVN 循环和/或模式？这是否需要对方法进行全面改革，还是我只是缺少一些简单的东西？

感谢您的任何想法！

【问题讨论】：

标签： php svn

【解决方案1】：

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

关键是将主干合并到开发分支以获取任何新的主干更改，然后在返回合并到主干之前测试开发分支。如果每个更改都有其自己的分支，那么开发人员会很快投入其中。

正如其他人已经提到的，员工的教育。员工教育没有例外，每个变化都有自己的分支机构。 SVN 中的副本既便宜又容易，因此没有真正的例外。

【讨论】：

【解决方案2】：

这是我们典型的开发周期；我们是“伪敏捷”；并以 2 周的发布周期运行。

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

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

下一个版本前一周；我们创建一个发布“标签”（本质上是另一个分支）并将其发送给 QA。如果此时您还没有将代码合并回主干，那么它不会在下一个版本中发布。（重要说明：此版本“标签”永远不会合并回主干。永远。）当 QA 发现错误时；他们被分配回开发人员。当开发人员修复它们时；它们的更改必须同时提交到发布标签和主干。

当发布日到来时；我们发布该标签上的所有内容。在发布后修复的情况下；我们遵循与我们在 QA 周期中相同的指导方针，这样如果有人在发布标签被剪切后将新项目合并到主干；它不会在紧急修复中意外发布。

起泡、冲洗、重复……

这本身可能无法回答您的问题；但希望这可以作为您可能希望如何设置开发过程的一个很好的外部观点。这不是我们最初的流程，而是我们在过去一两年中提出的方法，根据我的经验，这比我们以前的做法有了飞跃。

如果您想对此进行任何澄清；只要给我留言，我会根据需要更新。

【讨论】：

>他们的更改必须同时提交到发布标签和主干。提交标签？就个人而言，我认为最好只将修复提交到主干并在所有内容修复后再次标记它。通常标签是代码库在某一时刻状态的“只读快照”，不应该被修改。
你遇到的问题是，如果另一个开发者在标签被剪切后将他们的项目合并到主干，然后你重新标签，他们的项目现在已经发布了。
这缓解了 OP 描述的“即时发布项目”和“开发功能”之间的冲突问题
新建一个bug修复分支？那为什么不只在原来的分支上工作呢？

【解决方案3】：

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

【讨论】：

【解决方案4】：

我在这方面支持 Bart；问题是培训。在您的项目变得过于复杂而无法以其他方式管理之前，您需要让您的同事正确使用 SVN。从您的描述来看，您的分支计划听起来不错，但确实有一个人不遵循该计划会为其他人破坏它。

同样，在您的项目变得更复杂之前立即执行此操作。

【讨论】：

【解决方案5】：

首要任务是让您的员工了解 SVN 的工作原理及其背后的方法。不管你的计划多么优雅，如果他们不能遵循它，他们就不会。

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

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

任何涉及多个文件或主要工作的事情都在功能分支中完成。小错误修复或快速工作直接在主干中完成。在整个开发过程中，所有分支都与主干保持同步（主干每隔几天合并到分支中）。

当发布时间到来时，我们会将所有计划发布的功能合并到主干中。一个特性分支被合并、检查，如果好的，则移入稳定分支。对所有功能分支进行清洗、冲洗、重复操作。

一旦稳定完成，它就会被标记为发布，我们的构建系统现在可以基于新标签构建生产。

如果我们需要进行直接投入生产的紧急修复，则检查、更正标签并生成补丁。补丁应用于主干，然后馈入稳定和任何新功能分支。

【讨论】：

我想我将使用这个响应和 Jim 的组合，因为它是一个很好的开始模式。感谢您花时间帮助我！问候，罗宾