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