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

什么是Test-Driven Development

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

什么是Test-Driven Debug

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

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

TDD和DevOps的关系

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

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

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

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

Jenkins & Docker 快速部署 TDD

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

图画的很差，请谅解...

整个环节大体以下：

1. Develop push 代码到代码库。

2. 代码库用hook 触发Jenkins 启动。

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

4. 产生报告，须要的报告内容所有从report pool中获取。

5. 发送邮件报告。

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以后，咱们看看会怎么作这个测试工做。

1. 代码的checkout

2. 获取rule.xml

3. 运行Checkstyle

4. 把生成的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。

这样操做的优势是显而易见的。

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

2. Docker作的标准工具，能够迅速的部署一套符合需求的测试流程

3. 添加新的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，咱们将不按期作技术分享活动。