Php SVN web开发周期问题

我目前所在的组织使用SVN开发PHP应用程序。我们的开发周期一开始很简单，使用post-commit钩子进行提交更新web根目录，以便立即看到更改。然后，我们遇到了一个问题，开发特性阻碍了bug修复，阻止了修复文件被移动到生产环境中，有时还导致prod服务器出现问题

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

知道吗，我面临的分支完全不同步（因为有些人没有“理解”主干/分支的概念，而是在主干上开发），更改从一个私有分支合并到主干中，从而在合并来自当前版本分支的上个月的所有更改时，可能会丢失更多的代码

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

在这种背景下，我的问题是： 对于这种情况，您会推荐什么Web开发SVN周期和/或模式？ 这需要彻底的方法论改革，还是我只是缺少了一些简单的东西

---

谢谢你的建议

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

我支持巴特的观点；问题是培训。在您的项目变得过于复杂而无法管理之前，您需要让您的同事正确地使用SVN。从你的描述来看，你的分支方案听起来不错，但是一个人不遵守这个计划，其他人就会破坏它

---

同样，在您的项目变得更加复杂之前，现在就开始吧。

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

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

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

下一版本发布前一周；我们创建一个发布“标签”（本质上是另一个分支），并将其发送给QA。如果此时还没有将代码合并回主干，那么下一个版本就不会使用它。（重要提示：这个版本的“标签”永远不会合并回主干。）因为QA发现了bug；它们被重新分配给开发者。当开发者修复它们时；它们的更改必须同时提交到release标签和trunk

当发布日到来时；我们释放了标签上的所有东西。在发布后修复的情况下；当我们在QA周期中时，我们遵循相同的指导原则，如果有人在发布标签被删除后将一个新项目合并到主干中；它不会因紧急修复而意外释放

泡沫，冲洗，重复

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

---

如果你想澄清这一点；请给我留言，我会根据需要进行更新。

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

关键是将主干合并到devel分支中，以获取任何新的主干更改，然后在反向合并到主干之前测试devel分支。如果每一个变更都有自己的分支，那么开发人员很快就进入了变化之中

---

正如其他人已经提到的，工作人员的教育。员工的教育没有例外，每个有自己分支机构的变更也没有例外。SVN中的拷贝既便宜又容易，因此没有真正的例外理由。

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

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

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

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

当发布时间到来时，我们将采用所有预定的功能