敏捷与3C

Continuous Integration

Continuous Delivery

Continuous Deployment

小调查

on Continuous Integration

Inventor ?

小调查

on Continuous Integration

Inventor ?

Grady Booch, 1991

小调查

on Continuous Integration

Who first introduced CI in agile community ?

小调查

on Continuous Integration

Who first introduced CI in agile ?

Kent Beck, eXtreme Programming, 1997-1999

小调查

on Continuous Integration

What is the first framework about CI ?

小调查

on Continuous Integration

What is the first framework about CI ?

CruiseControl, 2001

        一天早晨，小C刚到公司便打开电脑，自己这个story做了两天了，本地也已经有了5次提交，看着周围小伙伴们接连sign off并领取新卡，自己不免有些着急，面包也没来得及吃就开始紧张工作了。

        你作为这个敏捷团队里的一名官方认证CI工程师，有什么想对小C说的？

国际持续集成工程师认证考试（ICIEC）200X年真题解析

材料分析 I

        小C的担心无非两点：1、工作超时被P；2、和小D的story产生很多代码冲突。

        问题1不属于“我”能解决的范畴。

        针对问题2，说明小C没有能够遵守“我”制定的持续集成最佳实践。可以做如下解释（首先请默念：响应变化 高于 遵循计划）：

参考答案

“在最初为了实现更快发布的XP实践中，为解决Integration Hell，要求每位开发人员每天至少合并一次代码到主干，这种代码管理方式（被kent beck）称作持续集成。”

       当然，一旦采用上述规则，你的项目主干上可能会存在写了一半的API、画了一半的按钮、甚至出现不可预料的bug......XP告诉我们要：

• 实现100%覆盖的测试，实现TDD能保证这一点
• 采用pair开发，或保证100%代码审查
• 不做特性开发，除非是必需
• 万一要开发特性，又怕下班前不得不提交只完成了一半特性的代码，就采用feature toggle

       目标：每天下班前上交自己的代码，且不会捅出什么大娄子。

        中午，小C麻烦小D给自己带份外卖，自己则坐在电脑前继续战斗。终于赶在下午水果时间前完成了最后一次提交。“呀!” 小C的心又提了起来，原来feature test挂了好几个，担心是自己代码的问题。小C看了一下failures列表，感觉自己的改动好像与这些failures无关，于是扭头问小D，得知feature test在他那边从来没全通过，就赶紧提交到master。

        你作为这个敏捷团队里的一名官方认证CI工程师，有什么想对小C和小D说的？

材料分析 II

        持续集成过程包括了运行构建、单元测试、集成测试、功能测试和代码质量分析等内容。

        持续集成的结果应及时通知整个团队，当出现问题时，团队应立即停止手头工作，并着手修复。

参考答案

“持续集成需要保证代码主干的正确性。而失败的集成将给后续提交带来不可预料的结果。因此CI正确是团队正常工作的前提。”

       在竞争激烈的市场环境下，持续集成的“正确论”遭遇挑战。仅仅因为某次提交导致整个团队进度受阻——为此还引入了额外的惩罚机制。这无疑会导致各种内忧外患的发生。

        “两次提交”是一种针对持续集成的改进方案，当程序员提交代码后，代码不立即合并到代码库中，而是在第三方实现本地合并，等持续集成成功，再将代码提交至代码库。这就避免了主干被人为损坏的可能。

        临下班前，小D找到你，他觉得团队目前采用的CI软件界面太丑了，明显不如高大上的XXX，速度快，bug少，还支持云服务。建议替换成XXX。

        你作为这个敏捷团队里的一名官方认证CI工程师，有什么想对小D说的？

材料分析 III

        你每天都合并到主干了吗？

        你TDD了吗？

        你100%测试覆盖了吗？

        你100%通过代码审查了吗？

        你保证功能完整不出bug了吗？

        你是在用CI工具，还是在采用持续集成实践？

        你是为了工具而敏捷，还是为了客户而敏捷，还是为了敏捷而敏捷，还是为了可工作的软件而敏捷？

参考答案

持续交付和Jez Humble

Jez Humble, author of CD

2015.4 - now         Owner of Jez Humble & Associates LLC

2014.8 - 2015.9     Vice President of Chef

2004.12 - 2014.7   ThoughtWorks

持续集成 vs 持续交付

背景:  

        经过200X年代最初几年的发展，许多人认为持续集成是个好主意，但是其宿主XP由于要求过于严苛，被人称作XSP（eXtremely Stupid Programming）。这其中包括TDD、100% ut和pair。因此，不像XP一样，持续集成实践开始在许多团队中被“接受”（实际上只是披着持续集成的外衣，而更像是Crystal的Frequent integration，频繁集成）。

        在这种情况下，持续集成的单独进化和流行成为必然。

“持续交付，是指在持续集成实践的基础上，运行自动化验收测试(acceptance test)，通过构建部署管线(deploy pipeline)，管理各级用于执行测试的类生产环境，拥有随时向生产环境发布的能力。”

“进一步说，持续交付，也只不过是向着更快发布又近了一步——从未离开敏捷的视野。”

持续交付和持续部署

持续交付：允许把每次构建都部署到production。

持续部署：每次构建都部署到production。

真的有区别吗？

持续部署要求团队拥有完备的测试、备份、发布、监控和除错能力，保证对整个敏捷开发过程的最高信心。

        实现不同于传统plan-based方式，通过精益思想、频繁发布、快速反馈、及时响应并作出改进，这就是敏捷过程的终极目标，也是团队创造力和创新的源泉。