理论部分: 内建质量

从本质上讲，内建质量要求每一个人在过程中不要传递低质量，而是保证自己的质量，对每个环节开展检查。通过建立更快速的缺陷检测和质量反馈，组织可以避免最终花费大量时间来遏制泄漏给客户的缺陷。

内建质量可以围绕四大支柱展开：

• 第一个支柱要求团队在源头建立质量。可靠的流程产生可靠的质量，流程是质量的总输入。源头质量的主要推动因素是团队对客户质量需求的理解、跨职能参与产品和过程的设计、以及开展根因应对的能力与实践。
• 第二个支柱要求每道工序都必须有够通过自检找到或预防缺陷的机会。这可以通过人工检查，也可以通过某种自动化机制在产生缺陷时发出警报。此处的目标是只要缺陷产生，随时发现它们。主要推动因素包括明确的书面产品质量标准、对源头输入的检查、对持续更新的工作实施标准化。
• 第三个支柱通过连续检查建立质量。每个过程都只负责接受高质量的产品。如果发现质量不佳，则立即通知先前的过程，以便不会继续产生缺陷。除了之前的所有先决条件之外，连续检查的主要启用系统是单件流和过程同步。当使用批处理和队列生产方法时，这使得下游的下一个过程很难找到第一个缺陷并提供允许生产者过程停止产生缺陷的反馈。缺少单件或小批量同步会产生批量生产缺陷的风险，并且问题可以隐藏，直到可以执行连续检查的稍后时间点。
• 第四个支柱是通过百分之百的检查来建立质量。

iCode与内建质量

针对开发人员向远程代码仓库推送变更的过程，iCode提供了内建质量的完整解决方案，实现了内建质量的第二个、第三个和第四个支柱：

• 在代码变更中的缺陷进入到远程仓库（并被其他团队成员和客户获取）之前，可以通过人工方式进行代码评审，也可以通过自动化流水线进行代码扫描、自动化测试，从而有机会发现其中的缺陷，起到预防缺陷传递的作用。
• 通过强制所有代码变更都需要进行合入前的检查，确保了每次合入的代码变更都是经过了检查的高质量变更，进而每个开发人员从远程仓库获取的代码也是高质量的。持续的检查为团队提供了更及时的质量反馈，有助于让缺陷更早发现、更早解决。

实操部分:

Chapter1:开启流水线评审

• 进入提交规则设置界面
• 勾选提交代码必须经过评审选项，强制要求每次向远程仓库提交的变更必须要评审通过才能合入
• 勾选开启iPipe流水线检查选项，启用机器评审
• 勾选一次只能提交一个commit选项，强制每次向远程仓库提交的变更中只能包含一次本地仓库提交
• 点击“保存”按钮

 

Chapter2:搭建评审流水线

Step 1：进入持续集成界面

首先保证你的项目已经开启了ipipe服务，通过左侧导航的ipipe进入持续集成页面, 点击屏幕中央的新建流水线:

Ipipe首页面

Step 2：选择监听的代码库

设置流水线名称为“评审流水线”，创建一个流水线的标识ID之后，点击蓝色的”+代码库/分支”按钮，选择代码库，目前效率云支持用户通过icode代码库或github上的代码库建立流水线:

选择icode或github代码库

在今天的实验里我们选择icode上现有的代码库，如上图所示, 找到我们在上一讲建立的代码库 javademo，在下面的分支里选择master, 消息类型选择change触发: 在这里，我们将代码push 之后，真正入库前的事件定义为change；而对应的, merge代表代码入库后触发；

现在关闭弹窗，继续完成后续的设置:

其他配置

• 触发方式选择“代码库变更自动触发”，也就是说当代码提交评审时，若符合监听分支规则，则流水线自动触发执行。
• 阻塞构建选项选择“不阻塞构建”，也就是说可以多个流水线触发消息可以同时启动多条流水线实例，无需排队等待上一次执行完成。
• 任务超时时间留空，表示无超时

Step 4：添加“构建”阶段

• 点击加号按钮开始添加流水线执行的阶段：
• 阶段名称输入“构建”
• 点击“添加新任务”开始为阶段添加具体的执行任务。

添加一个iscan代码扫描任务

• 选中“iScan代码扫描”
• 点击“添加” 按钮，所有设置采用默认即可；

• 我们再来添加一个新任务（并行）按钮

• 选择”Maven构建”

• 点击添加按钮
• 命令输入如下脚本，其他字段保留默认值：

mvn clean install package

set -x

mkdir output

mv ./target/spring-jsp-static-resource-0.0.1-SNAPSHOT.war ./output/

暂时不用理会制品打包上传和制作Docker镜像功能，我们点击页面最下面的确定，完成change流水线的配置。

Chapter3: 完成第一次代码提交

Step 1：修改代码

• 打开文件/src/main/java/com/javasampleapproach/jspresource/controller/WebController.java

• 修改代码第19行内容，将put方法里name的值改成”Your name”
• 保存文件

Step 2：提交变更到本地仓库

• 执行命令git add .，将变更添加到暂存区。
• 执行命令git commit -m "Change the return value"将代码提交到本地仓库，-m参数用于指定提交变更的说明信息“Change the return value”

Step 3：将本地仓库推送到iCode进行评审

• 尝试执行命令“git push”将本地仓库变更推送到远程仓库

由于之前在icode的提交规则中启用了“提交代码必须经过评审”选项，因此服务器提示禁止直接推送，必须使用git push origin HEAD:refs/for/master方式提交代码评审。

• 按提示提交代码评审执行命令git push origin HEAD:refs/for/master

• 在icode界面中点击“代码评审”

待评审的记录

• 你已经可以看到刚刚提交的代码评审了, 点击这条记录可以看到”持续集成”部分显示0/1条流水线已经完成，说明我们刚才配置的change流水线已经生效，等待2-3分钟，构建完成后的效果如下一张图-change流水线执行完毕

Change流水线在执行中

Change流水线执行完毕

Step5: 查看流水线执行情况

• 点击流水线名称的链接，进入流水线执行结果页面:

流水线执行结果

• 点击iScan代码扫描任务，点击页面下方的具体信息，可以查看本次代码静态扫描的结果，结果众包括本地变更的代码行数，缺陷数，缺陷的具体分布和位置

代码扫描的结果页面

• 现在点击左侧ipipe的链接，现在我们可以看到右侧的页面上已经有了构建记录:

Ipipe的流水线执行列表页

Chapter3: 完成第一次人工评审

Step 1：开启人工评审提交规则

• 进入提交规则设置界面
• 启用必须有评审人+2选项
• 启用禁止发起人自己+2
• 点击保存按钮

Step 2：进行评审

• 使用你在第一章节里建立的子账号登录
• 进入代码评审界面
• 点击进入刚刚提交的评审
• 点击java，查看该文件的变更情况
• 在变更后的代码行双击，添加代码行级别的评论
• 输入评论内容
• 点击保存按钮

• 点击“打分/评论”按钮
• 打分选择“+2”
• 编写评论
• 点击发表按钮

 

Step 3：代码合入

• 退出icode子用户，重新使用主账户登录icode并查看评审详情
• 评审状态已经变为“等待合入”
• 合入情况显示持续集成和人工评审都已经检查通过，可以合入
• java文件显示有一条评论
• 在评论上可以给与回复
• 点击合入按钮完成代码合入

• 查看代码库提交历史
• 历史顶部已经加入了刚刚合入的变更提交

恭喜，你已经成功完成了第一次合入经过了自动检查和人工评审的代码！