敏捷与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方式，通过精益思想、频繁发布、快速反馈、及时响应并作出改进，这就是敏捷过程的终极目标，也是团队创造力和创新的源泉。