Day Two -- Part2: 设计提交规范，代码评审规范，设计提交流水线

训练营往期回顾:

Day Zero – 开通效率云服务 <<

Day One 之理念篇: DevOps与敏捷，用户故事地图，价值流图

Day One 之实操篇--产品规划，定制看板，生成迭代计划

Day Two -- Part1: 托管你的代码

承接刚才的内容，在上一节课中我们已经将一份简单的示例代码托管在iCode上，接下来我们来为你的开发团队设定一些开发的规则: 代码提交的规范，代码入库前的质量检查和代码评审。最终我们将完成第一次正式的code change提交。

相关知识 ：质量内建

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

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

第一个支柱要求团队在源头建立质量。可靠的流程产生可靠的质量，流程是质量的总输入。源头质量的主要推动因素是团队对客户质量需求的理解、跨职能参与产品和过程的设计、以及开展根因应对的能力与实践。

第二个支柱要求每道工序都必须有够通过自检找到或预防缺陷的机会。这可以通过人工检查，也可以通过某种自动化机制在产生缺陷时发出警报。此处的目标是只要缺陷产生，随时发现它们。主要推动因素包括明确的书面产品质量标准、对源头输入的检查、对持续更新的工作实施标准化。

第三个支柱通过连续检查建立质量。每个过程都只负责接受高质量的产品。如果发现质量不佳，则立即通知先前的过程，以便不会继续产生缺陷。除了之前的所有先决条件之外，连续检查的主要启用系统是单件流和过程同步。当使用批处理和队列生产方法时，这使得下游的下一个过程很难找到第一个缺陷并提供允许生产者过程停止产生缺陷的反馈。缺少单件或小批量同步会产生批量生产缺陷的风险，并且问题可以隐藏，直到可以执行连续检查的稍后时间点。

第四个支柱是通过百分之百的检查来建立质量。不止包括功能性的检查，还包括性能，安全，稳定性等诸多方面的检查。

iCode与内建质量

iCode质量模型

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

1. 在代码变更中的缺陷进入到远程仓库（并被其他团队成员和客户获取）之前，可以通过人工方式进行代码评审，也可以通过自动化流水线进行代码扫描、自动化测试，从而有机会发现其中的缺陷，起到预防缺陷传递的作用。

2. 通过强制所有代码变更都需要进行合入前的检查，确保了每次合入的代码变更都是经过了检查的高质量变更，进而每个开发人员从远程仓库获取的代码也是高质量的。持续的检查为团队提供了更及时的质量反馈，有助于让缺陷更早发现、更早解决。

相关知识: 效率云的Change request机制

在持续集成的实践中，本地代码的提交规范是一项重要的团队实践，整个提交过程如下图:

持续集成中的6步提交法

一名开发人员在提交完代码后要观察线上流水线的执行情况，直到指定的流水线执行无误之后才可以继续开发；一旦发生错误或检查出BUG，开发人员要在尽可能短的时间内在本地修改BUG，再次提交直至流水线执行正确。

结合持续集成的质量内建四大支柱中的第一支柱我们发现，一旦线上流水线检测出BUG，这时代码已经入库！！已经将BUG带入了代码库。那么有没有可能将质量检查进一步前置呢? 答案是有的： 百度效率云参考google的presubmit机制，提出了change 流水线的概念，保证代码在入库前即可进行一系列的云端测试，只有通过测试的代码才能够合入代码库，最大程度的将质量检验前置，保证代码库的质量。我们称之为change request:

效率云建议的代码提交规范

参考文章: http://www.googblogs.com/efficacy-presubmit/

实操: 开启流水线评审，使用change流水线提交代码

设置提交规则

①  进入提交规则设置界面

②  勾选提交代码必须经过评审选项，强制要求每次向远程仓库提交的变更必须要评审通过才能合入

③  勾选开启iPipe流水线检查选项，启用机器评审

④  勾选一次只能提交一个commit选项，强制每次向远程仓库提交的变更中只能包含一次本地仓库提交

⑤  点击“保存”按钮

实操: 搭建评审流水线

持续集成入口

Step 1：进入持续集成界面，在iCode代码仓库左侧的导航中点击“持续集成”，进入该模块的iPipe流水线界面。初始状态下，iPipe中没有流水线，如下图：

iPipe初始化界面

Step 2：进入新建流水线界面，点击新建流水线-->新建流水线

新建流水线

Step 3：设置流水线的触发模式和监听分支规则

流水线配置

①  设置流水线名称为“评审流水线”

②  触发方式选择“自动”，也就是说当代码提交评审时，若符合监听分支规则，则流水线自动触发执行。

③  分支匹配方式选择“精确匹配”

④  精确匹配为“master”

⑤  匹配消息类型选择“Change”，也就是当代码提交时所触发的消息。

⑥ 点击添加按钮完成消息添加

⑦  阻塞构建选项选择“不阻塞构建”，也就是说可以多个流水线触发消息可以同时启动多条流水线实例，无需排队等待上一次执行完成。

⑧  任务超时时间留空，表示无超时

Step 4：添加“自动化扫描”阶段

流水线增加一个stage

① 点击加号按钮开始添加流水线执行的阶段：

② 阶段名称输入“自动代码扫描”

③  触发方式选择“自动触发”。自动触发是指流水线开始执行时或上一阶段成功执行时，执行阶段自动开始执行。

④ 失败策略选择“快速失败”，即阶段执行中只要有一个任务执行失败，后续任务不再启动。

⑤ 点击“添加新任务”开始为阶段添加具体的执行任务。

增加iscan代码扫描

⑥  选中“iScan代码扫描”

⑦  点击“添加” 按钮，所有设置采用默认即可

配置iscan扫描任务

⑧  点击添加新任务（串行）按钮

添加串行任务

⑨ 选择Maven构建

⑩ 点击添加按钮

添加maven构建

⑪  命令输入如下脚本，其他字段保留默认值：

cd complete

mvn clean test

⑫ 点击保存按钮

增加maven编译

实操: 完成第一次代码提交

Step 1：修改代码

① 回到刚才下载的springboot实例代码，用IDE打开文件complete/src/main/java/hello/HelloController.java

springboot示例代码

② 修改代码第11行的返回值：

return "{\"errno\":0,\"info\":\"Ok\"}";

③ 保存文件

Step 2：查看工作目录的代码变更情况

①  执行命令git diff

②  查看内容变更情况

执行git diff

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

①  执行命令git add .，将变更添加到暂存区。

②  执行命令git commit -m "Change the return value"将代码提交到本地仓库，-m参数用于指定提交变更的说明信息“Change the return value”

git add, git commit

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

①  尝试执行命令“git push”将本地仓库变更推送到远程仓库,由于之前在icode的提交规则中启用了“提交代码必须经过评审”选项，因此服务器提示禁止直接推送，必须使用git push origin HEAD:refs/for/master方式提交代码评审。

禁止直接git push

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

提交代码

③  在icode界面中点击“代码评审”，进入代码评审界面，选择"开发中"的评审请求。

选择开发中的评审

④  你已经可以看到刚刚提交的代码评审了。

让评审流水线执行成功

Step 1：查看评审流水线执行结果

查看提交前检查结果

①  执行结果显示“1项检查失败”，展开查看详情

②  持续集成失败，点击“评审流水线”查看流水线详情

③  流水线iScan代码扫描任务颜色为绿色，表示执行成功，点击这个任务节点

④  点击“查看详情”查看代码扫描报告

iscan结果页面

⑤ Maven构建任务颜色为红色，表示执行失败

Step 2：查看出错原因并解决问题

查看编译日志

①  点击执行失败的Maven构建任务节点

②  查看编译日志，日志提示测试失败，失败位置为HelloControllerTest的getHello测试方法，位于第29行，期望结果为"Greetings from Spring Boot!"，测试执行结果为"{\"errno\":0,\"info\":\"Ok\"}"

③  打开文件complete/src/test/java/hello/HelloControllerTest.java

查看JPATest case

④  查看第29行测试代码，可以看到期望结果等于"Greetings from Spring Boot!"，所以需要更新测试用例

⑤  将期望值改为"{\"errno\":0,\"info\":\"Ok\"}"

修改测试用例

⑥ 查看修改情况，执行命令git diff

再次执行git diff

⑦ 将变更提交到本地仓库，执行命令git commit --amend -am "Correct unit test expectation"

执行git amend

参数说明：

--amend：将本次提交与上一次提交合并为一次提交

-am：是-a和-m的缩写形式，使用-a时会自动进行git add .操作，-m用于指定本次提交的描述说明

⑧ 再次查看代码评审

⑨ 可以看到本次评审已经通过提交前的流水线检查

再次查看

实操: 完成第一次人工评审

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

① 进入提交规则设置界面

② 启用必须有评审人+2选项

③  启用禁止发起人自己+2选项

④  点击保存按钮

人工评审设置

Step 2：添加评审人

① 进入评审人设置界面

②  分支选择master

③  默认评审人选择子用户icode(这就是为什么课程刚开始的时候我们要求每个人建一个iCode的子账号)

④  点击添加按钮完成评审人添加

添加评审人

Step 3：进行评审，这里我们切换一下账号

①  使用icode账号登录

②  进入代码评审界面

③  点击进入刚刚提交的评审

iCode账号进入评审界面

④  点击HelloControllerTest.java，查看该文件的变更情况

⑤  在变更后的代码行双击，添加代码行级别的评论

⑥  输入评论内容

⑦  点击保存按钮

执行评审

⑧  点击“打分/评论”按钮

⑨  打分选择“+2”

⑩  编写评论

⑪  点击发表按钮

整体打分

Step 4：代码合入

① 退出icode子用户，重新使用主账户登录icode并查看评审详情

②  评审状态已经变为“等待合入”

③  合入情况显示持续集成和人工评审都已经检查通过，可以合入

④  HelloControllerTest.java文件显示有一条评论

⑤  在评论上可以给与回复

⑥   点击合入按钮完成代码合入

查看刚才的评审

⑦  查看代码库提交历史

⑧  历史顶部已经加入了刚刚合入的变更提交

查看提交记录

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

以上就是今天课程的全部内容，完成课程的同学请发以下两张截图：1. 代码库的提交记录；2.最近一次流水线的执行 完成打卡。

明天我们将重点介绍iPipe和iRepo,祝大家学习愉快 ~

打卡1: 提交记录

打卡2: 流水线执行