持续集成 - 构建分离的项目还是全部集成在一起？

我工作的一个项目，都会有这些应用程序：持续集成 - 构建分离的项目还是全部集成在一起？

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

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

我在考虑两个选项：

1）建立每个应用saparately

更难测试应用程序的集成
如果我在一个应用程序改变的东西，我需要小心所有其他应用程序
我需要将所有应用程序更新日志合并到一个文档中

2）把所有的应用程序到一个单一的构建

这似乎不错，生成单一的changelog
也许写测试应用程序集成？

那么，究竟是什么情况下，一些好的做法？也许选项2？

来源

2015-06-15 anderlaini

我投票去选择2到许多在其各个阶段的“进位”的发展与单片方法简单：

简单的集成 - 所有的作品都已经集成，大家对任何一件工作整个项目不在自己的沙箱中（真持续集成，如果你想的话） - 非常重要的，如果你也打算使用敏捷方法
集成测试不再是一个单独的活动，你可以做到这一点的一部分经常CI过程，因为你可以一起测试所有组件（可能用一个组合测试床而不是每个组件的专用测试床 - 成本较低）
更简单的相干/一致的源代码控制（即使零件有自己的回购，他们可以可以在整体风格统一管理的就像我在这个问答&一个建议： Build dependencies and local builds with continuous integration
可能更快的整体构建（不同的构建可以使用的空闲周期其他建立是困难时，他们独立编排 - 他们可能可能会更好“打包”，导致 c减少建设资源）

来源

2015-06-16 01:52:14

我同意你所说的一切。这是现实世界中的普遍做法吗？将不同的应用程序构建成单个部署包我正在寻找一些关于这方面的文章，但没有找到任何东西 – anderlaini

尚不常见（来自实施前景）。单个部署包中的多个应用程序：新鲜/最初的Linux发行版，几乎每个复杂/高级的嵌入式系统，安装或升级都是“单片”（用于检验计算/存储/网络/军事装备）。实际上它并不需要成为一个单一的部署包（除非你真的指的是一组或多或少相关的包，它们恰好一起部署）。这些概念在这里：http://www.martinfowler.com/articles/continuousIntegration.html –

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

来源

2015-08-19 03:58:51

持续集成 - 构建分离的项目还是全部集成在一起？

回答

相关问题