持续集成 - 构建分离的项目或构建一个整体？

Question

我正在开发一个拥有这些应用程序的项目：

- backend api   (nodejs)
- ios app       (objective-c)
- android app   (java)
- web site      (php)
- admin site    (php)
- client site   (php)

我的问题是关于版本控制和管理所有这些项目。

我正考虑两种选择：

1）逐步构建每个应用

• 更难以测试应用集成
• 如果我在一个应用中更改某些内容，我需要小心所有其他应用
• 我需要将所有应用更改日志合并到单个文档

2）将所有应用放入一个单一版本

• 生成单个更改日志似乎很好
• 也许会对应用集成进行测试？

-

那么，这个案例的一些好的做法是什么？也许选项2？

Answer 1

我的选择转到选项2.使用单片方法更容易在所有阶段“进行”开发：

• 更简单的集成 - 所有部分都已集成，每个处理整个项目任何部分的人都在同一页面上，而不是在他们自己的沙箱中（真正的持续集成，如果你想的话） - 非常如果您还打算使用敏捷方法，这很重要
• 集成测试不再必须是单独的活动，您可以这样做 部分常规CI流程，因为您可以将所有部分一起测试（可能使用单个组合测试平台而不是每个部件的专用测试平台 - 降低成本）
• 更简单的连贯/一致的源代码控制（即使这些部分有自己的 回购，他们可以像我一样以单片风格一起管理 本Q＆amp; A中建议： Build dependencies and local builds with continuous integration
• 可能更快的整体构建（不同的构建可以使用空闲周期 在其他构建中，当它们更难以协调时 独立 - 他们可能会更好地“打包”，导致 降低构建资源的成本）

Answer 2

我绝对不会选择选项2. Grady Booch在90年代早期就称之为持续整合。今天，他们想要使用“持续交付”一词。我说我们应该一直使用持续改进。无论如何，您希望能够交付，部署，投入生产应用程序，项目，“一个”可交付成果。你绝对不想混合应用程序。您可能需要将一个应用程序部署到生产中，而另一个应用程序出现问题。或者您只是对单个应用程序进行了非常快速的修复，并且您希望将其通过流程进行交付。出于这些原因，我不会选择选项2。