引言
对于客户或者需求方来说，可以集成交付的软件才是有价值的。
每个软件都有集成的过程，如果软件规模比较小，比如只有一个人而且没有外部依赖，那集成没什么问题。随着软件变得复杂，依赖变多，开发人员变多，那么早集成、常集成，就可以尽早暴露问题，做出相应的调整，防止在软件后期才发现问题，从而导致软件失败。
定义
大师Martin Fowler对持续集成是这样定义的:
持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
优点
- 降低软件风险
早集成，常集成，并且做了有效的测试，有利于尽早暴露问题和软件缺陷，了解软件的健康情况。假定越少的软件，对于维护和新业务开发都是有利的。
如果botslab每一个品类的设备都单独分支开发，不能及时集成进来，依赖问题、冲突问题、业务复用问题不能尽早解决，问题累积到一定程度解决成本会变大，业务发展是不会为代码重构让路的，那么软件质量的降低是必然的，很多项目都是这样失败的 - 减少重复过程
软件集成的过程看起来简单，但是做起来难。软件的编译，测试，审查，部署，反馈，这些重复劳动是非常耗时，且没有意义的，自动化集成可以让开发解放出来，做一些用脑袋的事情。
如果出现疏漏，会给下游的参与者带来额外工作量和项目质量的误判。软件的输出质量是会影响项目计划的，所以持续集成很重要的一点就是自动化 - 随时生成可以部署的软件
持续集成可以随时随地输出可以部署的软件，这一点对于需求方或客户是明显的好处。我们可以对客户说软件有多么好的架构，多么高质量的代码，但是对于客户来说，一个可以使用的软件才是他的实际资产。持续交付可以尽早的暴露产品问题和开发方向，客户才能给出有效的意见和开发重点。 - 软件是透明的
持续集成会生成软件构建状态和品质信息，经常集成可以看到一些趋势，预测一些软件质量走向。 - 团队信心
持续集成可以建立团队的信心，开发清楚的知道自己的代码产生了什么影响，测试对软件质量的预测稳定，产品或客户可以放心的需求了
步骤
- 统一的代码库
- 自动构建
- 自动测试
- 每个人每天都要向代码库主干提交代码
- 每次代码递交后都会在持续集成服务器上触发一次构建
- 保证快速构建
- 模拟生产环境的自动测试
- 每个人都可以很容易的获取最新可执行的应用程序
- 每个人都清楚正在发生的状况
- 自动化的部署
原则
- 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
- 开发人员每天至少向版本控制库中提交一次代码。
- 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
- 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
- 每次构建都要100%通过。
- 每次构建都可以生成可发布的产品。
- 修复失败的构建是优先级最高的事情。
近期评论