持续集成工作流程理念

Question

在我工作的软件开发环境中，我们有一组开发人员都在同一个（Java）代码库中工作（目前使用的是SVN）。 我注意到人们想要经常提交他们构建的内容而不“破坏构建”。因此，正因为这个原因，我正在研究像Git和Mercurial这样的工具，这些工具可以更容易地进行分支，特别是合并。

我看到的一件事是，如果开发人员提交“错误代码”，那么代码就会被所有人破坏。作为避免这种情况的一个想法，我想要一种拥有“中间单一功能”存储库的方法，该存储库只是当前的“主要”，只有该单个新功能的一个变更集。在成为主代码库的一部分之前，可以自动测试这样一个“中间单一特征”存储库（代码质量，单元测试，手动代码检查等）。

所以我想到的工作流程看起来像这样：。

1. 开发人员创建新功能并在每天本地提交。
2. 一段时间后，开发人员完成并提交整个变更集以集成到“主”存储库中。
3. 持续集成系统采用当前的“主”，应用变更集并检查代码（合并冲突，PMD，Findbugs，...），运行单元测试，检查编码风格等。
4. 如果CI系统决定“错误代码”，开发人员会收到有关原因的通知，开发人员必须解决上述问题。在这种情况下，主存储库保持不变。
5. 如果CI系统决定“足够好”，则代码会到达“首席开发人员”或“代码审核人员”，他们会检查所选解决方案并批准或拒绝该解决方案。
6. 然后，批准的变更集将包含在主存储库中，并且可供所有开发人员进行变基/合并。

我对这种工作流程有一些疑问：

• 你认为这在实践中是否会运作良好（即这是一个好主意还是一个真正的头脑风暴）？
• 你们之前有过这样的事吗？专业人士和骗子是什么？
• 是否有“准备好运行”的脚本/程序/工具/ ......可以在最短的时间内启动这样的工作流程（或这个想法的变体）？

感谢。

---

背景说明：

大约13年前，我在一家公司工作，他们在内部建立了类似的工作流程，他们有两个夜间构建：

1. '生产'版本：主代码库
2. '高级版：主代码库，包含所有已更改文件的所有新提交版本。

因为这是所有SCCS（锁定编辑 - 解锁模型）的基础，没有办法“经常提交”，你有代码更改和所有其他类型的讨厌效果的死锁。 我正在寻找的主要是关于我当时使用的更好的工具，然后使用今天更好的工具。

Answer 1

在我正在工作的公司，我们考虑过使用这种方法。最后我们选择使用更简单的东西。我们让自动构建在成功构建后设置标签，我们有一个工具可用于同步到该标签。因此，当有人破坏构建时，其他人仍然可以从存储库中获取工作版本。同步的工具还可确保如果您刚刚提交了某些内容，则您的更改不会被属于该标签的修订所替代。对我们来说这项工作非常完美，但它可能不适合您的情况。

此致

Sebastiaan

Answer 2

TeamCity具有预测试提交功能。

http://www.jetbrains.com/teamcity/delayed_commit.html