持续集成扫盲篇

一.基础概念

 1.持续基本Continuous integration (CI)

  持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,

  也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译发布自动化测试)来验证,

  从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件。

  

  持续集成强调开发人员提交了新代码之后,立刻进行构建、测试。根据测试结果,我们可以确定新代码和原有代码能否正确集成在一起

 2.持续集成的好处主要有两个

  • 快速发现错误,每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易
  • 防止分支大幅偏离主干,如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

 3.持续集成的目的

  • 可以让产品快速迭代,同时还能保证高质量,它的核心措施是代码集成到主干之前,必须通过自动化测试,只要有一个测试用例失败就不能集成。
  • 持续集成并不能消除bug,而是让他非常容易的发现和改正。

二.持续交付

 1.持续交付Continus delivery (CD)

  持续交付指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段

  

  持续交付可以看作持续集成的下一步,他强调的是,不管怎么更新,软件是随时随地可以交付的

三.持续部署

 1.持续部署 continuous deployment(CD)

  持续部署是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境

  持续部署的目标是,代码在任何时候都是可部署的,可以进入到生产阶段,前提是能自动化完成测试构建部署等步骤。

四.持续集成的一般流程

 1.根据持续集成的设计,代码从提交到生产,整个过程有以下几步:

  • 提交:流程第一步,是开发者向代码仓库提交代码,所有后面的步骤都始于本地代码的一次提交
  • 测试(第一轮):代码仓库对commit操作配置了钩子(hook),只要提交代码或者合并进主干,就会跑自动化测试
  • 构建:通过第一轮测试,代码就可以合并进主干就算交付了,交付后就进行构建,进入第二轮测试,所谓构建指的是将源码转换为可以运行的实际代码,比如安装依赖配置各种资源等
  • 测试(第二轮):构建完成,就要进行第二轮测试,如果第一轮已经涵盖了所有测试内容,第二轮忽略。
  • 部署:通过第二轮测试代码就是一个可以直接部署的版本,将这个版本所有文件打包发到生产服务器
  • 回滚:一旦当前版本有问题,就回滚到上一个版本的构建结果.

猜你喜欢

转载自www.cnblogs.com/datastart/p/10552671.html