Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
持续集成及反模式	   张凯峰	              1	  
关于我	ThoughtWorks中国公司高级软件咨询师InfoQ中文站资深编辑技术图书译者                          2	  
议题	2007. 01       持续集成的概念           持续集成反模式                     3	  
持续集成	区别于传统的在开发完成后才开始质量控制和集成的方式,持续集成实现了频繁的、增量的软件质量控制,从而提高软件质量,缩短软件发布的周期。			《持续集成》第二版,译者:雷镇,作者:Martin Fowlerhttp://artic...
传统的集成存在什么问题	•  用大量的时间集成不同来源的代码•  集成时间甚至长于开发时间•  每个人都要花很大的力气才能构建系统•  发布在即,bug却越来越多•  ……                       5	  
于是…	     集成时问题多、      主干质量不稳      时间长	        定	          容易引入Bug	     本地代码堆积       不想不敢更新     很久才进行集         代码	    ...
究其根源	•  缺乏有效的反馈手段,集成过程不透明、缺乏管理•  对当前主干质量情况缺乏一个基本认识•  集成频率太低。一次集成太多内容导致成本高、时 间长、容易出错                            7	  
如果引入持续集成…	   小步频繁集成,           错误及时得到    快速反馈	            修复	             尽早修复Bug	                     每次集成成本    主干质量稳...
持续集成是一种软件开发的实践。通过这个实践团队的成员频繁整合他们的工作,通常每人每天至少集成一次,通过不断地练习,最终达到每日多次集成。每次集成通过自动化的编译和测试等手段进行验证,来达到尽快发现集成错误的目的。                ...
一次成功的持续集成						《持续集成理论和实践的新进展》,肖鹏http://www.infoq.com/cn/articles/ci-theory-practice	                              ...
持续集成的原则	•  只维护一个源代码库•  自动化构建•  自动化测试•  每人每天向代码主线提交代码•  每次提交触发构建•  保持快速构建•  在模拟生产环境下测试•  每个人可轻易获得最新的可执行文件•  每个人都能看到进度•  自动...
持续集成平台	•  Jenkins/Hudson•  TeamCity•  ThoughtWorks Go                     12	  
持续集成的反模式	•  标准化类反模式•  自动化类反模式                   13	  
反模式一:非最小依赖	•  需要开发者定义和配置环境变量•  需要开发者安装大量工具才能构建                     14	  
模式一:最小依赖	•  将需要预安装的工具减至最少•  将构建和部署所需环境配置减至最少•  Tips  –  自动化建立依赖的过程  –  制作镜像                      15	  
反模式二:只能在个别机器上构建	   “在我的机器上构建没有问题啊!”                 16	  
模式二:在独立专用的机器上构建	•  选择CI服务器需要考虑 –          统 –     构 –    馈 报                 17	  
反模式三:非独立构建	•  自动构建依赖IDE的设置•           构                  18	  
模式三:独立构建	•  与IDE分离的构建脚本	•  CI可以调用命令行开始构建	                      19	  
反模式四:通过文件系统管理和共享文件	•  在团队成员机器上管理文件•  通过文件系统共享        20	  
模式四:所有文件版本化	•  由版本控制系统管理文件•  授权访问给特定用户                 21	  
反模式五:积攒大量的代码质量问题	•  等待大量的代码问题爆发•  增加维护的成本•  影响既有的功能实现                  22	  
模式五:构建的阈值	•  构建时检查 –  代码测试覆盖率 –  代码圈复杂度•  让构建失败,并通知开发团队                   23	  
反模式六:弱反馈	•  很少的反馈•  垃圾邮件反馈              24	  
模式六:持续反馈	•  CI发布持续、自动的反馈•       馈 –  馈 –  邮 –  RSS                  25	  
反模式七:手动参与构建过程	•  手工不断重复同样的构建•  部分自动构建,需要额外的手工配置                      26	  
模式七:构建过程全部自动化	•  从源代码开始,完全自动化构建•  创建不依赖IDE的构建脚本,能从命令行调   用                      27	  
反模式八:耗时的人工代码审查	•  专门的代码审查会议•  无视代码审查                28	  
模式八:自动代码审查	•  运行自动代码分析找到通常问题•  代码分析作为自动构建的一部分                    29	  
反模式九:没有自动化测试	•  不运行测试•  没有回归测试•  人工测试                  30	  
模式九:自动化测试	•  回归测试•  自动化构建的重要部分                31	  
总结	•  每个团队有最适合自己的持续集成方式•  不为了持续集成而持续集成                       32	  
谢谢	           33	  
Upcoming SlideShare
Loading in …5
×

持续集成中的反模式

905 views

Published on

AgileTour 2011 天津

Published in: Technology
  • Be the first to comment

持续集成中的反模式

  1. 1. 持续集成及反模式  张凯峰  1  
  2. 2. 关于我 ThoughtWorks中国公司高级软件咨询师InfoQ中文站资深编辑技术图书译者 2  
  3. 3. 议题 2007. 01 持续集成的概念 持续集成反模式 3  
  4. 4. 持续集成 区别于传统的在开发完成后才开始质量控制和集成的方式,持续集成实现了频繁的、增量的软件质量控制,从而提高软件质量,缩短软件发布的周期。   《持续集成》第二版,译者:雷镇,作者:Martin Fowlerhttp://article.yeeyan.org/view/2251/94882  4  
  5. 5. 传统的集成存在什么问题 •  用大量的时间集成不同来源的代码•  集成时间甚至长于开发时间•  每个人都要花很大的力气才能构建系统•  发布在即,bug却越来越多•  …… 5  
  6. 6. 于是…  集成时问题多、 主干质量不稳 时间长  定  容易引入Bug  本地代码堆积 不想不敢更新 很久才进行集 代码  成  6  
  7. 7. 究其根源 •  缺乏有效的反馈手段,集成过程不透明、缺乏管理•  对当前主干质量情况缺乏一个基本认识•  集成频率太低。一次集成太多内容导致成本高、时 间长、容易出错 7  
  8. 8. 如果引入持续集成…  小步频繁集成, 错误及时得到 快速反馈  修复  尽早修复Bug  每次集成成本 主干质量稳 低,出错几率 定  小  8  
  9. 9. 持续集成是一种软件开发的实践。通过这个实践团队的成员频繁整合他们的工作,通常每人每天至少集成一次,通过不断地练习,最终达到每日多次集成。每次集成通过自动化的编译和测试等手段进行验证,来达到尽快发现集成错误的目的。 9  
  10. 10. 一次成功的持续集成      《持续集成理论和实践的新进展》,肖鹏http://www.infoq.com/cn/articles/ci-theory-practice  10  
  11. 11. 持续集成的原则 •  只维护一个源代码库•  自动化构建•  自动化测试•  每人每天向代码主线提交代码•  每次提交触发构建•  保持快速构建•  在模拟生产环境下测试•  每个人可轻易获得最新的可执行文件•  每个人都能看到进度•  自动化部署 11  
  12. 12. 持续集成平台 •  Jenkins/Hudson•  TeamCity•  ThoughtWorks Go 12  
  13. 13. 持续集成的反模式 •  标准化类反模式•  自动化类反模式 13  
  14. 14. 反模式一:非最小依赖 •  需要开发者定义和配置环境变量•  需要开发者安装大量工具才能构建 14  
  15. 15. 模式一:最小依赖 •  将需要预安装的工具减至最少•  将构建和部署所需环境配置减至最少•  Tips –  自动化建立依赖的过程 –  制作镜像 15  
  16. 16. 反模式二:只能在个别机器上构建  “在我的机器上构建没有问题啊!” 16  
  17. 17. 模式二:在独立专用的机器上构建 •  选择CI服务器需要考虑 –  统 –  构 –  馈 报 17  
  18. 18. 反模式三:非独立构建 •  自动构建依赖IDE的设置•  构 18  
  19. 19. 模式三:独立构建 •  与IDE分离的构建脚本 •  CI可以调用命令行开始构建  19  
  20. 20. 反模式四:通过文件系统管理和共享文件 •  在团队成员机器上管理文件•  通过文件系统共享 20  
  21. 21. 模式四:所有文件版本化 •  由版本控制系统管理文件•  授权访问给特定用户 21  
  22. 22. 反模式五:积攒大量的代码质量问题 •  等待大量的代码问题爆发•  增加维护的成本•  影响既有的功能实现 22  
  23. 23. 模式五:构建的阈值 •  构建时检查 –  代码测试覆盖率 –  代码圈复杂度•  让构建失败,并通知开发团队 23  
  24. 24. 反模式六:弱反馈 •  很少的反馈•  垃圾邮件反馈 24  
  25. 25. 模式六:持续反馈 •  CI发布持续、自动的反馈•  馈 –  馈 –  邮 –  RSS 25  
  26. 26. 反模式七:手动参与构建过程 •  手工不断重复同样的构建•  部分自动构建,需要额外的手工配置 26  
  27. 27. 模式七:构建过程全部自动化 •  从源代码开始,完全自动化构建•  创建不依赖IDE的构建脚本,能从命令行调 用 27  
  28. 28. 反模式八:耗时的人工代码审查 •  专门的代码审查会议•  无视代码审查 28  
  29. 29. 模式八:自动代码审查 •  运行自动代码分析找到通常问题•  代码分析作为自动构建的一部分 29  
  30. 30. 反模式九:没有自动化测试 •  不运行测试•  没有回归测试•  人工测试 30  
  31. 31. 模式九:自动化测试 •  回归测试•  自动化构建的重要部分 31  
  32. 32. 总结 •  每个团队有最适合自己的持续集成方式•  不为了持续集成而持续集成 32  
  33. 33. 谢谢   33  

×