你如何处理重构与合并需求之间的紧张关系？

StackOverflow https://stackoverflow.com/questions/200757

题

我们在交付新版本时的政策是在我们的VCS中创建一个分支并将其处理给我们的QA团队。当后者发出绿灯时，我们会标记并发布我们的产品。分支保持接收（仅）错误修复，以便我们可以创建技术版本。这些错误修复随后合并在主干上。

在此期间，主干会看到主要的开发工作，并且可能会受到重构更改。

问题在于需要有一个稳定的主干之间存在紧张关系（以便错误修复的合并成功 - 如果代码已经被提取到另一个方法，或者移动到另一个方法，通常不能在引入新功能时需要重构它。

我们的政策是在经过足够的时间并且分支足够稳定之前不进行任何重构。在这种情况下，可以开始对主干进行重构更改，并在主干和分支上手动提交错误修复。

但这意味着开发人员必须等待一段时间才能在主干上进行任何重构更改，因为这可能会破坏从分支到主干的后续合并。并且必须手动将分支中的错误移植到主干上是很痛苦的。在我看来，这妨碍了发展......

你如何应对这种紧张局势？

感谢。

有帮助吗？

解决方案

这是一个真正的实际问题。如果您需要支持多个版本并为每个版本分支，情况会变得更糟。更糟糕的是，如果你有一个真正的R＆amp; D分支。

我的偏好是允许主干以正常速度继续运行而不是坚持，因为在商业发布时间非常重要的环境中我永远不会认为我们应该允许代码稳定（“什么” ，你的意思是你在一个不稳定的状态下发布它？“。”。

关键是要确保在将bug迁移到主分支时，为bug修复创建的单元测试已经过渡。如果您的新代码更改真的只是重新分解，那么旧的测试应该同样有效。如果你的更改不再有效，那么你不能在任何情况下解决修复问题，你需要有人认真思考新代码流中的修复。

经过几年管理这类问题，我得出结论，您可能至少需要4个代码流来提供适当的支持和覆盖，以及一系列非常严格的流程来管理它们之间的代码。这有点像能够用4种颜色绘制任何地图的问题。

我从未在这个问题上找到任何真正好的文献。它将不可避免地与您的发布策略以及您与客户签署的SLA相关联。

附录：我还应该提到，有必要将分支合并作为特定里程碑写入主分支的发布时间表。如果你有一群努力工作的开发人员正在实现他们的工作实现功能，那么不要低估将你的分支机构聚集在一起所需的工作量。

其他提示

在我工作的地方，我们为每个非平凡的变化（功能添加或错误修复）创建临时的，短期的（少于一天 - 几周）工作分支。 Trunk稳定且（理想情况下）可能始终可释放;只有已完成项目才会合并到其中。从树干承诺的一切每天都会合并到工作分支中;这可以在很大程度上自动化（我们使用Hudson，Ant和Subversion）。 （最后一点是因为通常比以后更快地解决任何冲突更好。）

我们使用的当前型号在很大程度上受到优秀文章的影响（由Henrik Kniberg撰写的）之前的插件： 版本控制多个敏捷团队 。

（在我们的例子中，我们有两个scrum团队在一个代码库上工作，但我认为这个模型即使对一个团队也很有用。）

额外的分支和合并有一些开销，但不是太多，真的，一旦你习惯了它并且使用工具变得更好（例如 svn merge --reintegrate 很方便） 。不，我不会总是创建一个临时分支，例如对于较小的，低风险的重构（与当前正在工作的主要项目无关），可以通过一次提交到主干来轻松完成。

我们还维护一个较旧的发布分支，其中不时修复关键错误。不可否认，如果代码的某些特定部分与分支相比显着增加，则可能存在手动（有时单调乏味）的合并工作。 （随着我们不断向主干（内部）发布增量，并让市场营销和产品管理部门决定何时进行外部发布，这有望成为一个问题。）

我不确定这是否可以直接回答您的问题，或者您是否可以在您的环境中应用此问题（使用单独的QA团队和所有人） - 但至少我可以说您描述的紧张局势对我们来说不存在我们可以随时自由地重构。祝你好运！

我认为可以通过在开发过程中添加以下成分来解决紧张问题：

  1. 持续集成
  2. 自动功能测试（我认为你已经计入单元测试）
  3. 自动递送

    4. 通过持续集成，每次提交都意味着构建所有单元测试都会被执行，如果出现任何问题，您会感到惊慌。你开始更多地工作，你不太愿意分支代码库。

    通过自动功能测试，您只需单击按钮即可测试应用程序。通常，由于这些测试需要更多时间，因此这些测试每晚进行一次。 有了这个，版本控制的经典角色开始失去重要性。您不会根据版本及其成熟度决定何时发布，而是更多的业务决策。如果您已经实施了单元和功能测试，并且您的团队正在提交经过测试的代码，那么head应始终处于可以发布的状态。不断发现和修复错误并发布错误，但这不再是循环过程，它是连续的过程。

    你可能会有两种类型的批评者，因为这意味着要改变一些长期的实践。首先，持续交付的范式转变似乎与管理者相反。 ＆＃8220; Aren我们冒着运送大错误的风险？＆＃8221;如果您看看Linux或Windows发行版，这正是他们正在做的事情：向客户推送发布。而且，由于您使用自动测试套件，危险性进一步降低。

    接下来，QA团队或部门。 （有人会认为问题在于它们本身的存在！）它们通常会对自动化测试产生厌恶。这意味着学习新的，有时是复杂的工具。在这里，最好是通过这样做来传播。我们的开发团队开始致力于持续集成，同时使用 Selenium 编写功能测试套件。当QA团队看到该工具正在运行时，很难反对其实施。

    最后，我所描述的过程并不像开发过程中的addig 3成分那么简单。这意味着您对软件开发方式的深刻改变。

在我工作的地方，我们继续在主要分支中进行重构。如果合并变得棘手，它们只需要在临时基础上进行处理，它们都是可行的，但偶尔会花费一些时间。

也许我们的问题来自于我们的分支必须具有相当长的寿命（长达18个月），并且必须对它们进行许多修复。

确保我们只从非常稳定的代码分支可能会有所帮助，但不会那么容易...... :(

不隶属于 StackOverflow
scroll top