|
持续集成，顾名思义，就是多次频繁地提交代码到版本库的主干，与已有的代码进行集成。实际上，持续集成包含了编译、提交、测试、发布、回滚等多个动作。而且，为了“持续集成”能够频繁地进行，这一系列流程需要实现自动化。 持续集成的目标是让正在开发的软件（位于版本库的主干位置）一直处于可工作状态。所以，一旦构建或测试过程失败，开发团队就要立即修复它。 持续集成是软件开发的一项优秀实践。持续集成可以给软件开发带来以下好处：
高效地使用持续集成可以满足我们快速、高质量交付软件的需求。因为测试左移，可以避免开发完成之后才开始测试带来的进度、质量不能保证的问题；更早地发现缺陷，可以降低修复成本；随时获得可用的软件版本，满足交付的需求…… 虽然持续集成是敏捷开发提出来的实践，但是，对于那些实施GJB5000A，仍然使用传统的瀑布模型进行开发的组织来说，同样具有借鉴意义。 很明显，需求明确之后就开始写代码，把功能实现之后再进行测试的方式远没有边写代码边集成、边测试的这种开发方式优越。让集成、测试更早地开始，更早地发现缺陷，以更小的成本修复缺陷，它不香吗？如果再实现自动化构建、自动化测试，它不更香吗？ 有些组织在不能按期交付软件的时候，总是抱怨缺少开发人员。诚然，资源不足是影响交付进度的主要因素，但是，像持续集成这么好的实践为什么不尝试在组织内部推行呢？ 增加人手很重要，过程的持续改进也重要。 两手都要抓。 这正是： 持续集成好实践，软件开发要借鉴 快速交付质量高，谁用谁人都说好 参考书目：持续交付：发布可靠软件的系统方法，作者：[英]Jez Humble,David Farley，译者：乔梁，出版社：人民邮电出版社 |
|
|
