前言
在上一篇博文：[基于Docker的持续交付系列（ 二）：阿里云code帮你实现持续交付第一步]中，我们通过用阿里云code实现了从代码提交到镜像编译最终到部署容器服务的自动化，虽然简化了流程，但从持续集成的角度看，我们似乎漏掉了很重要的一步——集成，因为我们的代码在没有经过测试的情况下就发布上线了，这是何其危险的事情。现在，随着阿里云持续交付平台的介入，我们终于可以实现我们标题所讲的——基于Doecker的持续交付。
用到的工具
同样，我们还是使用到了下述几个平台：
- 使用的持续交付平台为阿里云持续交付平台
- 使用的的代码托管工具为阿里云code
- 使用的容器镜像服务为阿里云开发者平台
- 最终的产品镜像将部署到阿里云容器服务
上；
准备工作
这里，我们假设您已经使用了阿里云开发者平台和阿里云容器服务的产品，并熟悉相应的配置。
操作步骤
绑定您阿里云帐号的AccessKeyId和AccessKeySecret
- 阿里云持续交付平台(CRP)需要您绑定您阿里云帐号的AccessKeyId和AccessKeySecret到平台之上，以便于获取您的镜像仓库信息以及您部署在容器服务上的应用信息。
- 您可以点击页面右上角的个人信息，选择阿里云RAM授权tab，进行信息填写（目前容器镜像服务尚未支持子帐号授权，所以需要填写主帐号ak）
![_2016_08_16_10_36_32]
(https://yqfile.alicdn.com/df7977df4c5616a5821bb94c2cde7852c69d7e4f.png)
配置您的工作流
我们依旧选择阿里云持续交付平台提供的demo项目（java）作为模板，在第一个stage中配置代码更新，编译/测试两个任务，实现代码从提交到测试的第一次集成。需要注意的是，为了在编译镜像的过程中可以使用编译产出物，这里编译产出物功能一定要开启。
在第二个stage中配置镜像构建，部署容器服务两个任务，可以看到，当您正确填写了AccessKeyId和AccessKeySecret之后，CRP可以通过接口调用取到您的镜像仓库列表和部署在容器服务上面的应用列表。选择您要push的镜像仓库和需要更新的应用（这里需要更新的应用必须在容器服务的管理页面上生成重新部署的触发器）
修改代码并静静地观察
我们可以故意把测试修改错误，这样第一个stage中的编译/测试任务会运行失败，这时候我们很及时地得到了第一次集成的反馈。
同时，我们也可以像基于Docker的持续交付系列（ 二）：阿里云code帮你实现持续交付第一步中提到的一样，将页面中的文字修改一下，然后通过容器服务提供的公网地址去查看效果。
需要注意的是，由CRP提供的编译产出物，是一个名为package.tgz的压缩包，所以需要在Dockerfile中进行解压操作：
COPY package.tgz /tmp
RUN tar -xvf /tmp/package.tgz -C /tmp
RUN cp /tmp/boot-api.war /usr/local/tomcat/webapps/tmp
总结
终于的终于，一个有点儿模样的基于docker的持续交付流程跑通了，由于平台间的联调以及暂不支持子帐号等限制，目前该功能只针对部分用户开放，如果您恰好对这方面感兴趣，可以加入我们的旺旺答疑群：CRP用户答疑（群号：1525660614），也可以直接联系我们的客服小妹：crp技术支持，以进行开通。
展望
虽然流程跑通了，但目前CRP所能提供的也还只是代码层面的单元测试或者简单的集成测试（需要每次安装相应依赖），还不能提供基于镜像的测试环境，这可能是下一步多个平台需要合作实现的功能。
