持续集成

来自lfzyx
跳转至: 导航搜索

持续集成(continuous integration)是软件工程中的一种实践,用于每天多次合并所有开发工作副本至一个共享的主线。这个术语源自极限编程(extreme programming) 的一个最佳实践,主要目的是防止积累问题。持续集成可以看作是早期迭代增量式开发所主张的定期集成实践。[1]

原则[编辑]

  • 单一代码库;项目源代码存放于一个版本控制系统, 让所有人都能从这里获取最新的源代码.持续集成提倡开发人员频繁提交修改过的源代码。可以用最新的检出构建系统,并且不需要额外的依赖,减少分支,使用集成代替维持多个软件版本。
  • 自动构建;一个简单的命令就可以构建系统。自动化构建包括自动化集成,自动部署。在许多情况下,构建脚本不仅仅编译二进制文件,同时还生成文档、网页、统计和分发介质。
  • 自动测试;一旦代码构建完成,自动运行所有测试以确定符合期望。
  • 每人每天提交代码至主线;通过定期提交,每个提交者可以减少修改代码带来的冲突。传统开发模式中,开发进行到特定阶段后再集成到一起进行测试,但很多Bug在项目早期就存在了,如果在最后集成的时候才发现问题,开发者需要在集成阶段花费大量的时间来定位Bug。但如果尽早检查,系统中的一小部分冲突可以使团队成员尽早沟通。建议至少一天一次提交所有更改,进行自动构建与自动测试的检验,以尽快发现集成错误 。对于持续集成来说,集成越频繁,效果越好。
  • 每次提交的代码可以被构建;为了验证是否正确集成,每次提交至当前工作版本的代码应该可以被构建。持续集成服务器监控版本控制系统,一旦有变化,构建会自动进行。
  • 保持快速构建
  • 复制生产环境进行测试;有测试环境可能会导致系统部署到生产环境时失败,因为生产环境和测试环境有很多不同。
  • 简单的获取最新成果
  • 每个人都可以看到最新版本的结果
  • 自动部署;许多持续集成系统允许构建完成后运行脚本,脚本用于发布系统到测试环境,使每个人可以看到成果。进一步可以在生产环境中自动化部署。

集成过程[编辑]

  1. 开发人员从源代码仓库检出最新程序
  2. 开发人员编写代码、测试用例,并提交更新结果给版本控制仓库
  3. 持续集成服务器根据触发条件,从版本控制仓库检出最新代码,进行编译、测试,并进行打包,如有必要,实现产品部署、发布
  4. 开发人员检查集成过程中出现的问题

优点[编辑]

  • 易于定位错误。也就是当你的持续集成失败了,说明你新加的代码或者修改的代码引起了错误,这样你很容易的就可以知道到底是谁犯了错误,可以找谁来讨论
  • 及早在项目里取得系统级的成果。因为代码已经被集成起来了,所以即使整个系统还不是那么可用,但至少你和你的团队都已经可以看到它已经在那了
  • 改善对进度的控制。这点非常明显,每天都可以看到哪些功能可以使用,哪些功能还没有实现
  • 更加充分地测试系统中的各个单元
  • 能在更短的时间里建造整个系统
  • 有助于项目的开发数据的收集
  • 与其它工具结合的持续代码质量改进
  • 与测试工具或者框架结合的持续测试
  • 便于Code Review
  • 便于开发流程的管理

软件[编辑]

buildbot

cruisecontrol

参考文献[编辑]

  1. Continuous integration