持续集成及反模式	   张凯峰	              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
×

持续集成中的反模式

786 views
718 views

Published on

AgileTour 2011 天津

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
786
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

持续集成中的反模式

  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  

×