敏捷与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