什么分支来测试持续集成？答案

【问题标题】：What branch to test continuous integration?什么分支来测试持续集成？
【发布时间】：2016-04-05 18:12:38
【问题描述】：

对于一个新项目，版本控制分支结构如下，

* develop
* feature
* master

我是否应该在不同的分支上编写测试感到困惑，比如一个新的分支test 分支还是仅仅在现有的开发分支中？在feature or develop 分支中编写单元测试并在测试分支中编写集成测试是一种好习惯。如果不是，测试应该去哪里？保持单独的测试分支有什么好处和坏处？我的开发分支将经常提交和推送。

感谢您的任何回答。

【问题讨论】：

标签： unit-testing testing continuous-integration tdd

【解决方案1】：

我过去所做的是为 QA 构建功能并为开发服务器开发。

这样您可以看到开发人员的最新代码，当您合并功能更改时，可以将其推送给 QA。

我相信，您应该始终在两个分支上运行单元测试和集成测试。

测试应该是构建过程的一部分。

【讨论】：

赞成“两个分支”，但应该是“所有三个分支”。如果需要分支，则需要 CI。
@DaveSchweisguth - 我倾向于创建分支只是为了让我有时间在不影响其他人的情况下进行重大更改，因为我做一些实验。这些分支不需要 CI，因为它们实际上只是暂时有用。然后它们被合并到正确的开发分支中，该分支上应该有 CI。
如果您有一个测试套件可以在您的开发机器上以合理的时间运行，并且您始终记得运行它并且严格要求仅在它通过时合并。

【解决方案2】：

您所描述的并不是真正的持续集成，它看起来很像瀑布 - 因为所有这些分支。任何这些分支中的工作都不会（持续地）与任何其他分支中的工作集成。

这意味着您的测试的影响也将仅限于您执行该测试的分支。要将其应用于其他分支，您需要等待您的更改集成到相应的分支中（或双重提交，但这会添加到分支合并期间要解决的冲突列表中）。而且，当然，您需要在需要测试结果的每个分支中重复测试 - 因为分支上下文不同，并且在一个分支中获得的结果不一定在另一个分支中可重复。

当然，没有什么能阻止您在部分/所有这些分支中使用 CI 工具，但这并不能使其成为持续集成。

在这种情况下（我假设 feature 分支最终将合并到 developed 中，并且从那里开始，当足够稳定时，所有内容都会合并到 master 中）你会产生最大的影响通过在 develop 中工作并可能在 master 中重复执行测试以验证在 master 中完成的任何其他额外工作（如果有的话）没有破坏事情，从而减少工作量。

在真正的持续集成中，所有开发工作都在单个/主分支中完成，包括大部分/所有测试。每个人都在同一个页面上，没有暴露于质量水平的中断以及由于分支合并和没有重复工作所需的额外无法量化的工作量。更不用说一个更简单和更清晰的过程 - 你甚至不需要问这个问题:)

【讨论】：