持续集成 - 构建独立的项目还是合二为一？答案

【问题标题】：continuous integration - build separated projects or build all in one?持续集成 - 构建独立的项目还是合二为一？
【发布时间】：2015-06-15 17:36:08
【问题描述】：

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

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

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

我正在考虑两种选择：

1) 分别构建每个应用程序

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

2) 将所有应用整合到一个版本中

生成单个变更日志似乎很好
也许可以为应用集成编写测试？

那么，对于这种情况，有哪些好的做法？也许是选项 2？

【问题讨论】：

标签： continuous-integration integration-testing versioning project-management

【解决方案1】：

我的投票投给了选项 2。使用整体方法更容易在所有阶段“进行”开发：

更简单的集成 - 所有部分都已集成，处理整个项目任何部分的每个人都在同一页面上，而不是在自己的沙箱中（真正持续集成，如果你愿意） - 非常如果您还计划使用敏捷方法，这很重要
集成测试不再是一个单独的活动，你可以做到常规 CI 流程的一部分，因为您可以一起测试所有部分（可能使用单个组合测试平台，而不是每个部分的专用测试平台 - 降低成本）
更简单的连贯/一致的源代码控制（即使片段有自己的 repos，它们可以像我一样以单一的方式一起管理本问答中建议： Build dependencies and local builds with continuous integration
可能更快的整体构建（不同的构建可以使用空闲周期在其他更难编排的构建中独立 - 它们可能会更好地“打包”，从而导致降低构建资源成本）

【讨论】：

我同意你所说的一切。这是现实世界中的常见做法吗？将不同的应用程序构建到单个部署包中。我正在寻找一些关于此的文章来阅读，但一无所获
还不常见（从实现的角度来看）。单个部署 pkg 中的多个应用程序：全新/初始 linux 发行版，几乎每个复杂/高级嵌入式系统的安装或升级都是monolithic（例如计算/存储/网络/军事设备）。实际上，need 不是一个 single 部署包（除非你真的是指一组或多或少相关的包，它们恰好被部署在一起）。概念在这里：martinfowler.com/articles/continuousIntegration.html

【解决方案2】：

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

【讨论】：