快速部署TEST-DRIVEN DEVELOPMENT/DEBUG环境

摘要：关注的目标就是在代码提交之后，顺利且迅速的把新的功能部署到产品环境上。由于是，那么单元测试，回归测试，集成测试，都是实现的手段。高质量的产品需求书和高质量的自动化集成测试用例毫无疑问，是高质量软件的保证之一。

Test-Driven Development 测试驱动开发，这个词儿各位技术大大必定耳熟能详，我作为一个曾经的Develop, ops,现在的DevOps从业者，这次想来跟大家聊聊Test-Driven Development。测试驱动开发传统意义上就是先写测试用例，再做代码实现，这样就能明确代码功能，减少开发无用功能的时间，很多好处，就不赘述了。

下面聊聊我想要说的TDD。
DevOps这一位置是互联网产品逐渐成熟之后，为了满足互联网开发&发布周期的特点所提出的一个新的岗位要求。关注的目标就是在代码提交之后，顺利且迅速的把新的功能部署到产品环境上。

其实这是一个很宽泛，涵盖内容比较多的话题，但是重中之重，显然是在于代码质量。所以我们内部提出的测试驱动开发，意义不仅仅在于单元测试用例先于开发代码之前的编写，而在与通过真正的测试报告来推动代码的Bug修复。所以应该是Test-Driven Debug。由于是Test-Driven Debug，那么单元测试，回归测试，集成测试，都是实现TDD的手段。

在整个DevOps的流程的上游，就是探究如何把这一系列的测试及时的反馈给Develop以帮助其改进代码质量。

测试用例的编写是非常重要的，我们的最终目标是PM写出产品需求之后，测试人员能够和开发人员一同进入编码流程，开发人员进行代码编写的同时测试人员进行自动化集成测试用例的编写。这对测试开发人员和PM都提出比较高的要求，一是PM提出的需求能够足够详细到最终功能的描述，其次要求测试人员能够仅根据功能描述完成测试用例的编写。这样同时进行的功能编写和功能测试还能促进PM的需求文档进一步的完善。

高质量的产品需求书和高质量的自动化集成测试用例毫无疑问，是高质量软件的保证之一。

其次，作为DevOps的职责之一，就是怎么把这个过程流转起来，规范化，形成固定的软件发布过程。

我们在内部搭建了一套即插即用的软件测试流转平台，整套流程使用的是Jenkins+Docker 的实现方式，Jenkins是标准的配置管理工具，有非常丰富的插件。Docker的优势在于随用随部署，并且能够把不支持rest接口的工具做成支持rest 接口的工作方式，再加上Jenkins本身就支持rest接口，这样我们在部署整套系统的过程中，就不需要依赖目录/文件共享的方式，全部使用rest协议，为Jenkins之间的job实现了解耦。
我们先看下构成图：

图画的不好，请谅解...

整个环节大致如下：

Develop push 代码到代码库。

代码库用hook 触发Jenkins 启动。

Jenkins调用Checkstyle,Pmd等测试job，测试参数从report pool获取，最终产生的report存入report pool。

产生报告，需要的报告内容全部从report pool中获取。

发送邮件报告。

report pool暂时使用Elastic search充任，不仅作为report的报告池，还中转了一些必要的配置文件，譬如规则文件等。

sendmail是必须的，每次测试结束之后发送的邮件是push Develop的唯一手段，也就是说，这个step是整个项目的脸面，有没有效果全看sendmail做的是不是够“触目惊心”了。

我们要求所有的Develop每天必须定时检查邮件，来获知测试结果，在项目后期必须当天解决bug，如果有任何延时必须上报pm以进行资源调配，以保证项目按时发布高质量的代码。

于此同时，将配备一个SPL去trigger并且push这一过程，给项目按时发布配备双重保证。

那么Docker是如何使用到这套环境中的呢？
譬如本例中的heckstyle, 这是最普遍的java代码风格检查工具，执行命令如下：

java -jar /root/checkstyle-xxx.jar -c rule.xml -f xml /var/jenkins/src -o /root/result.xml

很简单一个命令，按照rule.xml定义的代码规范，对/var/jenkins/src目录下的源代码进行扫描，输出的结果写入/root/result.xml中。

在使用Docker之前，我们的做法是Jenkins 的一个job checkout代码，然后在shell script 执行这条java命令，把输出的result.xml做为发布文件，给之后Jenkins的Checkstyle做为输入，并生成Checkstyle的summary report，这两个项目必须指定一个能共享的文件目录，以便信息交换，明显制约了项目部署。

这种做法在Docker出现之前，几乎是唯一的实现方式。在用了Docker之后，我们看看会怎么做这个测试工作。

代码的checkout

获取rule.xml

运行Checkstyle

把生成的Checkstyle的report上传到report pool

以上四项操作都集成在docker里面，做成image.

Jenkins所要做的就是调用docker api接口，两条命令:

curl -l –H xxxxxxxxxx http://server:port/containers/create?name=checkstyle
curl -X POST http://server:port/containers/checkstyle/start

完了之后，checkstyle产生的report就会进入report pool。

获取 report:

curl -XGET http://server:port/checkstyle/reports/checkstyle_report.xml

生成Checkstyle 的 Trend graph。

这样操作的优点是显而易见的。

Jenkins 的各项工具之间充分解耦，可以随时部署随时使用，不局限在某一个物理设备上

Docker做的标准工具，可以迅速的部署一套符合需求的测试流程

添加新的Jenkins工具不需要在Jenkins主机上安装各种工具，破坏原有的结构，使用Docker的rest api可以轻松的实现各种工具的即插即用。

配置管理过程中使用Docker的优势还有很多，我这里只述及了很小的一部分。

在需要快速开发的互联网时代，如何快速搭建一套软件质量保证的环境也是面临的挑战之一，通过Jenkins和Docker，我们能够迅速搭建一套符合要求的测试流程，并给提供给Develop及时的反馈，推进Develop对bug的Fix，提高Bug fix率从而提高代码质量。

有了这套系统，连接Develop和Tester，相信能更好的push 软件代码质量的提高，从而为快速部署和快速发布，为整个DevOps的流程打下坚实的基础。

原文作者来自 MaxLeap 团队_Service&Infra 成员：Kevin
原文链接：https://blog.maxleap.cn/archives/719

欢迎关注微信订阅号：从移动到云端
欢迎加入我们的MaxLeap活动qq群：555973817，我们将不定期做技术分享活动。