是读书还是思考

从“CI搭建兽”到“流水线即代码”

2017-03-11  本文已影响1842人  程序员吾真本

本文是2017年3月13日晚9点在“AHA面对面”线上分享的“单件流的力量-伍斌_Ben面对面”的操练步骤，这里是报名链接。

IMG_0861.PNG

操练目的

练习在CloudBees Jenkins Enterprise上手工配置部署流水线，使得每次代码提交，都能自动触发该部署流水线，并将这个过程可视化，以便一眼就能看到谁的代码提交在哪个环节引起了什么质量问题，以便快速进行修复。

因为本次操练的主要目的是手工搭建部署流水线，为节省时间，被部署的代码并不是一个完整的Web应用程序，而是使用了一个Java应用程序和一个Robot Framework (Python) Web UI自动化应用程序：前者仅仅是一个用Maven创建的有单元测试的简单Java应用，后者仅仅是Robot Framework官网上用于演示用的webdemo应用程序。用两者的结合来模拟一个完整的Web应用程序。

在ThoughtWorks中国区，大家亲热地把用手工搭建部署流水线的人称为“CI搭建兽”，意指这种手工配置过程既繁琐费神又毫无乐趣，比较原始，比那些已经进化的人所从事的工作要低级。;-))

而更加高级的工作应该是“流水线即代码”的实践，来让配置脚本能与代码一起进行版本控制。这样的好处是：Ops可以不用通过访问生产环境，就能知道生产环境上的配置情况；非运维人员如Dev，就有机会去学习这些运维配置代码并且加以修改，提升整个团队的DevOps能力；另外工具能方便地读取这些代码，来自动化地维护基层设施，大幅度提升Ops的工作效率。想了解更多相关的DevOps的良好实践，不妨阅读我的文章“实例化DevOps原则”。

为了知道“流水线即代码”到底有多甜，需要先吃一点“CI搭建兽”的苦。本文会先描述“CI搭建兽”的辛苦手工工作，最后会把这些手工工作用10行“流水线即代码”写出来并加以运行。

准备工作

环境准备

本文以macOS Sierra 10.12.3为例来准备环境。

单独运行自动化单元测试

在配置流水线前，先看看Java应用程序的单元测试能否运行通过。

单独运行自动化Web UI测试

再看看Python的自动化Web UI测试程序能否正常运行。

运行CloudBees Jenkins并查看插件

再看看流水线所依赖的两个插件是否已安装。

CI搭建兽的辛苦手工工作

先看看要搭建的流水线的样子。这个流水线有两个Stage：一个是COMMIT，用来针对第#53号代码提交运行自动化单元测试；另一个是ACCEPTANCE，用来在单元测试运行通过后，针对同样的代码提交运行基于Web界面的自动化验收测试。


要搭建的流水线的样子

创建流水线的第一个Stage：COMMIT

首先创建流水线的第一个Stage——COMMIT，来运行自动化单元测试。

让COMMIT Stage单独自动触发

咱们需要试一试COMMIT Stage能否随着代码提交而自动触发单元测试。

git add .
git commit -m "call method checkUsernameAndPassword() twice"

创建流水线的第二个Stage：ACCEPTANCE

这个ACCEPTANCE Stage是用来运行Robot Framework Web UI自动化测试的。

将两个Stage串起来

现在来把第二个Stage ACCEPTANCE挂到第一个Stage COMMIT之后，使得第一个Stage正常运行结束后，能自动触发第二个Stage继续运行。

git add .
git commit -m "delete duplicated method checkUsernameAndPassword()"

创建一个视图来可视化Deployment Pipeline

用视图将上面两个Stage串起来的配置进行可视化，以便方便地看到谁的代码提交在哪个环节引起了什么质量问题。

让视图可视化一次代码提交

现在用上面创建的Deployment Pipeline视图，来可视化一次代码提交

git add .
git commit -m "call method checkUsernameAndPassword() twice again"

让代码编译失败一次

让代码编译失败一次，看看流水线有什么变化。

git add .
git commit -m "call method abc()"
Screen Shot 2017-03-11 at 5.35.33 PM.png

让单元测试运行失败一次

让单元测试运行失败一次，看看流水线有什么变化。

git add .
git commit -m "make unit test failed"
Screen Shot 2017-03-11 at 5.43.36 PM.png

让Web UI测试运行失败一次

让Web UI测试运行失败一次，看看流水线有什么变化。

git add .
git commit -m "make web ui test failed"
Screen Shot 2017-03-11 at 6.29.18 PM.png

让整个流水线成功运行一次

git add .
git commit -m "make web ui test passed"
Screen Shot 2017-03-11 at 6.36.38 PM.png

10行代码搞定“CI搭建兽”的全部手工工作

下面看看如何用“流水线即代码”的实践，用10行Groovy代码搞定“CI搭建兽”的全部手工工作。而这10行代码都放到一个名为Jenkinsfile的纯文本文件中，下面会配置Jenkins，让它运行这个文件的Groovy脚本和配置语句。

先在Jenkins的Web UI里面定义一个流水线

在Jenkinsfile里面编写Groovy脚本来定义流水线

node {
    stage('COMMIT') {
        echo 'The COMMIT stage'
        sh 'mvn -f <full path>/jenkins-mobile-banking/mobilebanking/pom.xml clean test'
    }
    stage('ACCEPTANCE') {
        echo 'The ACCEPTANCE stage'
        sh 'robot <full path>/jenkins-mobile-banking/robotframework-webdemo/login_tests'
    }
}

这里，Jenkins一旦见到了node语句，就要为这个流水线分配executor和workspace，所以如果没有node语句，流水线就不会被执行。

stage语句指定了Stage；echo语句用来在console上打印一句话，方便查看运行结果；sh语句指定了要在Unix/Linux机器上运行一句脚本，如果是在Windows机器上，则要用bat语句。

在COMMIT Stage里面的sh语句，执行了maven命令，来运行单元测试，其中mvn命令指定了pom.xml文件的位置；在ACCEPTANCE Stage里面的sh语句，执行了Robot Framework的Web UI 自动化测试。

运行一下流水线

git add .
git commit -m "update Jenkinsfile"
Screen Shot 2017-03-12 at 11.35.52 AM.png

部署流水线与单件流

单件流指的是，正在制作的产品的各个模块，能从最初的对其增加价值的加工步骤，直接传递到下一个增值加工步骤进行加工，并最终被传递到客户手中，在这个过程中，各个步骤之间没有发生等待或者排队的现象（参见《丰田套路》）。

而如果在各个步骤的传递过程中发生了等待或排队，那就等同于建立了库存。软件开发中常见的库存包括排队等候开发的需求、排队等候测试的代码、排队等待修复的缺陷、排队等待上线的产品特性、甚至Ticket和邮件系统；

隐藏很深的库存可以由诸如那些有固定期限（比如每月一次）的“用户验收测试”的流程来造成——月初几天就开发测试完毕的产品特性必须要被存放近一个月，等到月底“用户验收测试”后才能继续往下游走。软件开发中的上述库存就是让项目延期的最大原因。

企业如果能做到单件流，那么就相当于消灭了库存，让价值在不同环节之间流动得最快，进而实现了全局优化。

这次操练所搭建的部署流水线，可以作为一个工具来可视化软件开发从代码提交之后的价值流。如果代码在各个Stage之间都无须排队且自动化地流动，那么就实现了Continuous Deployment，也就是在代码提交之后实现了软件开发最高效的单件流。

操练成就匠艺
全栈软件开发者的技术操练社区：bjdp.org北京设计模式学习组
QQ群号：235913915，微信订阅号：bjdp_org，网站：www.bjdp.org

上一篇 下一篇

猜你喜欢

热点阅读