支持自动化测试（调用ZTP，ZTP是我司自产的一个自动化测试工具，支持自动化脚本录制、回放等工作，其工作原理与robotframework比较类似，ZTP工具支持批处理脚本调用，故可以集成到jenkins中）。
当时，我们还想在Jenkins上集成更多的功能，包括：
改进websphere-deploy插件，支持界面部署WebSphere应用包（这个计划后面搁浅了，主要是脚本方式已经能支持绝大部分WAS集群的部署了）。
应用环境迁移，通过将应用环境迁移过程自动化为Jenkins中的任务，实现应用环境迁移过程的自动化和可视化（目的就是想实现研发、测试及生产都是一套环境，测试通过后的环境能直接迁移到生产上去，当时只是做运维的一种本能的想法，但也由此引发了对Docker的关注）。
与业务监控系统相结合，形成流程化的跨多个Jenkins任务的、整体的应用环境部署自动化和可视化，为将来生产环境部署的自动化和可视化作准备（曾经研究过一段时间 jenkins的FLOW插件，当时FLOW插件的版本还比较低，功能还很弱，引入第三方的工作流工作量会比较大，而事实上这种流程化的编译部署过程实用性也比较低，这事就慢慢搁浅了）。
目前我所在的产品线所有的项目都已经采用Jenkins进行编译、打包、代码走查及自动部署到测试环境和准生产环境（运营商项目的生产环境发布后面会逐渐由我司自主开发的另一利器“云应用管理平台”来支持，后面还会讲到）。 基于Docker的应用发布 前面讲了，关于应用环境迁移的想法引发了我对Docker的兴趣，实际上这时已经是2014年的6月份了，于是就跟一些同事自学鼓捣一下，当时Docker 1.0才刚刚发布，当时也就把官网的例子都做了一遍，参考官网作了Hadoop的镜像，自己又作了WebSphere的镜像，搭建了Registry，断断续续的作了一些东西，算不上很深入，而Docker本身也在不断发展，感觉隔几天就有一个新版本发布出来。
Docker大潮来势汹涌，到9月份的时候，我一开始说的那个巨大项目的运营商中有个技术专家提出了要用Docker来作应用发布平台，当时简直是不谋而合，于是有了一个项目，也就可以明正言顺的进行Docker研究了，不过既然已经是一个正式的项目了，那光有几个爱好者是不够的，需要有正规军了，于是请出了公司技术委员会下属的一个研发团队，大约有六七人，也就是“云应用管理平台”的开发团队，一起进行相关的研究。给生产环境用的发布平台跟我们前面讲的用jenkins作的自动部署还是有些不同的，生产环境上版本的发布一般是有严格限制的，包括版本要求、时间要求（升级时间、故障率和故障解决时间）等，这一点是与现在的互联网企业升级自家的系统是完全不同的。
“云应用管理平台”围绕着Docker进行了大量的开发工作，制作了主机管理、容器管理、集群管理、版本计划管理、版本执行管理等等，其架构如下图：
1）Jenkins打包镜像
自动获取SVN代码版本
使用Dockerfile打包镜像，并自动上传到Docker Registry。
2）集群配置
应用基本信息配置
集群应用绑定
环境变量配置
固定端口号配置
3）制定发布计划
选择镜像版本（Docker Registry API获取镜像列表）
选择主机，并设置启动的容器实例数