我们应该如何基于容器来进行软件的持续交付（二）？

接着上一篇的内容 如何基于容器来进行软件的持续交付的（一），我们有讲到“持续交付是文化，自动化是基石，垮职能团队协作是根本”，本文将以软文的形式介绍持续交付平台WiseBuild结合Rancher容器管理平台我们是如何进行跨职能团队协作的。

基础设施自动化

使用Rancher理由很简单，Rancher是目前市面上唯一一个能满足开箱即用的容器管理平台，同时能够支持多种编排引擎，如Rancher自己的Cattle，Google的K8S,以及Docker官方的Swarm作为容器编排引擎。同时Rancher提供的Catalog应用商店能够帮助研发团队自主创建所需要的服务实例。

基于Rancher提供的Environment我们分别为开发，测试，以及运维创建了独立的环境。确保不同职能人员之间对于环境的隔离性需求。

持续交付流水线

建立持续交付流水线的核心问题是如何定义企业的软件交付价值流动。

正如上文所说，创建持续交付流水线的本质就是定义软件的交付的价值流动，反应正式的软件交付流程。价值的流动则涉及到团队中各个职能的成员的高度协同。

基于容器的持续交付实践当中以镜像作为在不同职能人员之间的价值传递物。

开发流水线

开发人员：频繁提交持续集成，通过持续的编译，打包，测试，镜像构建，自动化验收测试等环节产生可测试的候选镜像列表(如：0.1-dev)。

• 以源码仓库为起点，开发人员频繁提交，每一次代码变更都要立即在流水线中传递；WiseBuild持续交付平台支持定时周期触发，代码变更检查以及Webhook等多种触发方式。
• 提交测试阶段从技术角度断言整个系统是可运行的，该阶段会进行编译，运行一套单元测试，并进行代码质量分析,WiseBuild持续交付平台设计遵循“Build In Docker, Build With Docker, Run With Docker” 基于容器技术全面减少对于异构构建环境的支持，并且默认提供了当前主流的编程语言的编译，以及测试支持。同时用户可以根据需要在持续交付流水线中集成Sonarqube进行代码的质量跟踪和管理。
• 自动化测试阶段，从功能交付断言整个系统是能够满足客户规范和要求的，WiseBuild持续交付平台支持基于Rancher或者Rancher Compose在柳树县中自动部署镜像到Rancher平台，同时内置了Selenium,Robotframework，Cucumber等主流自动化测试工具和框架。
• 手动测试阶段，当新的代码提交部署到rancher环境后，开发人员同时可以快速的进行手动测试，确保新提交的代码在测试环境中是可用的，并且满足相关的功能需求。
• 镜像构建，当代码提交通过了整个流水线的持续验证后将会产生响应版本的镜像文件。

基于流水线中的过程质量和代码质量数据，团队可以快速处理典型的代码质量问题，避免技术债务的产生。

总而言之，开发流水线可以帮助团队频繁的进行代码集成并且通过单元测试，代码静态分析，自动化验收测试等技术实际帮助开发人员快速的发现和解决问题，并且产生可待测试的镜像列表。

测试流水线

测试人员：从候选测试镜像列表中，选择需要测试的目标镜像，标记为测试版本(将0.1-dev标记为0.1-test)，并且将待测试镜像自动部署到验收测试环境，完成手动探索性测试，对于已测试完成的镜像标记为预发布版本(0.1-test 标记为 0.1-beta)。

在待测试镜像列表中选择镜像，发布到开发用Docker Registry仓库。

对于测试人员而言，流水线的起点则变为待测试的镜像列表，基于WiseBuild创建Docker类型流水线，可以支持测试人员快速创建测试环境并且运行相关的自动化测试脚本，同时满足手动探索性测试的需求。

支持使用自动化触发方式，如‘1.0.*-beta’的形式，当监听docker registry有符合规则的镜像产生后自动触发流水线。

支持手动触发，测试猿人可以手动选择服务该规则的镜像进行手动触发，一键准备测试环境，运行自动化验收测试等。

自动化部署流水线

运维人员：从预发布镜像列表中选择镜像部署到预发布环境，并且在验证通过后标记为release版本（如将0.1-beta 标记为 0.1-release）,并且发布到生产环境。

与自动化测试流水线相同，运维人员可以建立独立的部署流水线，从待发布的镜像列表中选择镜像发布到生产环境Registry中，并且设置流水线的自动或者手动触发，实现对于预生产环境的一键部署。

小结

WiseBuild持续交付平台支持对接基于Dokcer Registry标准的镜像仓库服务，包括Docker Hub, Docker Registry, Habor，阿里云等等。