持续集成(一)基本概念简要介绍

本章主要简单讲述【开发模型】及【持续集成和交付】基本概念

• 目前市面上的公司一般都是用Jenkins进行持续集成操作

首先简单提及一下【瀑布模型】和【敏捷开发】模型

• 瀑布模型&＃xff1a; 简单来说&＃xff0c;就和工厂流水线一样&＃xff0c;一个环节完了后进入下一个环节&＃xff08;即从设计–>开发–>测试–>开发改bug–>预发布–>生产等&＃xff09;&＃xff0c;各环节人员管理自己的事就行&＃xff0c;在开发过程中客户只能通过文档来了解产品

  所以它有个最大的弊端就是&＃xff1a;下游工作的开展严重依赖于上游的交付完成情况,造成了严重的人力资源浪费.

• 敏捷开发模型&＃xff1a; 即以客户需求为导向&＃xff0c;快速迭代功能型开发(和客户打交道型)

  在软件项目构建初期会切分成很多独立小项目来进行开发&＃xff0c;所有的人都要同时的工作(不再依赖于上游)&＃xff0c;最大的特色是客户会参与到软件开发的过程中,能够及时响应客户的需求

  像这样的开发模式&＃xff0c;在政府项目中比较多见&＃xff0c;它是以客户的需求为导向来进行快速迭代开发&＃xff0c;最主要的是多于客户沟通&＃xff0c;多了解客户需要什么。每次发布的版本多以小版本为主。

为什么要首先提及开发模型呢&＃xff1f;

• 按照我的个人理解简单说下

因为目前大部分公司其实实行的都是一个 【敏捷开发】模式&＃xff0c;那针对敏捷开发这种模型&＃xff0c;通常版本都是以小版本发布为主&＃xff0c;需要我们短时间进行一个项目的快速迭代&＃xff0c;那针对这种快速迭代的方式&＃xff0c;持续集成和持续交付就不可避免成为其中重要的一环&＃xff0c;可以加速项目的交付&＃xff0c;加快开发和测试这边的一个效率

持续集成&＃xff08;Continuous integration&＃xff09;&＃xff1a; 即频繁地&＃xff08;一天多次&＃xff09;将代码集成到主干。 就是让产品可以快速迭代&＃xff0c;同时还能保持高质量。 它主要是在开发阶段执行&＃xff0c;它的核心措施是&＃xff0c;代码集成到主干之前&＃xff0c;必须通过自动化测试。只要有一个测试用例失败&＃xff0c;就不能集成。

• 举个例子&＃xff1a;一般我们进行UI/API自动化用例部署后&＃xff0c;只要开发那边Git提交了代码&＃xff0c;就会自动触发我们的用例执行&＃xff0c;然后发送测试报告&＃xff0c;从某种意义上来说&＃xff0c;其实就是进行冒烟测试&＃xff0c;只是这一部直接自动集成了

那持续集成有什么优点呢&＃xff1f;

&＃xff08;1&＃xff09;可以快速发现错误。每完成一点更新&＃xff0c;就集成到主干&＃xff0c;可以快速发现错误&＃xff0c;定位错误也比较容易。
不像瀑布模型一样到最后产品都完成开发时&＃xff0c;才提交测试&＃xff0c;那到时候遗留的bug就会很多&＃xff0c;会花费很多时间成本&＃xff08;2&＃xff09;防止分支大幅偏离主干。如果不是经常集成&＃xff0c;主干又在不断更新&＃xff0c;会导致以后集成的难度变大&＃xff0c;甚至难以集成。
一般在开发阶段&＃xff0c;不同的开发不同的需求都会拉不同的分支&＃xff0c;等这个分支的代码测试全部验证通过后才会合到master分支&＃xff0c;持续集成


持续交付&＃xff08;Continuous delivery&＃xff09;&＃xff1a; 频繁地将软件的新版本&＃xff0c;交付给质量团队或者用户&＃xff0c;以供评审。如果评审通过&＃xff0c;代码就进入生产阶段。

持续交付可以看作持续集成的下一步。可以理解为在 【预发布阶段】&＃xff0c;它强调的是&＃xff0c;不管怎么更新&＃xff0c;软件是随时随地可以交付的。

持续部署 &＃xff08;continuous deployment&＃xff09;&＃xff1a; 是持续交付的下一步&＃xff0c;指的是代码通过评审以后&＃xff0c;自动部署到生产环境。

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