前言
在上一篇文章中讨论了容器服务提供的交付能力，在本文中我们将讨论如何从零搭建一个持续交付系统。
对于大多数公司而言，选择一个合适自己的持续交付系统是尤为重要的一件事情，不同的公司、不同的业务使用的场景也各不相同，因此要根据自己的业务场景与发展方向来选择合适的方案。根据不同的业务场景与交付方式，阿里云容器服务提供了三种不同的持续交付方案。
基于Jenkins的持续交付方案
![20.png]()
基于Jenkins的持续集成和持续交付方案是所有方案中最灵活、能力最强的方式，但也是需要客户自主运维的方案。对于现有提供持续交付的SaaS服务而言，很难既覆盖简单性与可扩展性。而对于定制化需求明显的开发者而言，开源的Jenkins一直是持续交付系统的第一选择。容器服务为了让开发者可以更简单的使用Jenkins进行容器交付，我们提供了容器服务的Jenkins部署插件，可以直接在构建任务中推送Docker Compose模板到容器集群；提供了Java、C++、Python、Nodejs、Golang等语言的Jenkins Slave，开发者可以直接使用这些Slave快速实现一个分布式集成的持续交付系统。在Slave中内置了简单的容器集成流程，开发者可以通过配置的方式将一个完整的持续集成流程在Slave中运行起来。
Jenkins的方案是所有方案中，功能最强大的。之所以选择Jenkins作为容器服务支持的开源方案的原因在于：
- Jenkins在国内的开发者中认可度较高，很多创业公司的自建持续交付系统的选择大部分都是Jenkins，便于开发者可以在老的系统上直接进行容器化的持续交付。
- Jenkins的能力远不止我们上文中提到的这些，良好的开源社区给Jenkins带来的反哺，让Jenkins可以通过插件的方式满足很多系统无法满足的场景，比如对于刚刚使用容器的客户可能会倾向于使用Jenkins的混合发布的方式，即将应用交付到容器服务的同时也交付到远程的虚机上，进行应用的灰度测试，逐步的迁移。
- Jenkins拥有良好的扩展性，在开发Jenkins插件的时候，可以发现Jenkins内部实现机制几乎可以通过插件的方式让开发者扩展所需的任何一个位置，对于很多定制化场景而言，这会是选择Jenkins的决定性因素。
- Jenkins拥有持续交付系统中最重要的也是最棒的流水线（pipeline）系统，在Jenkins2.0以上的版本中，内置了流水线（pipeline）的支持，这表示了未来Jenkins在持续集成与持续交付领域的发展趋势与能力。
基于CRP的持续交付方案
![21.png]()
CRP是阿里云推出的一款提供持续集成与持续交付功能的SaaS服务。同常见的持续交付系统类似，CRP也提供了一个可扩展的流水线。开发者可以将自己的持续集成与持续交付流程转换为一条DAG图的流水线（pipeline）。比如在本文中提供了一个简单的容器化的持续交付的流水线定义。分为五个阶段：代码检出、集成测试、镜像构建、推送镜像、部署应用。每次提交代码，代码仓库都会触发CRP进行持续集成，运行用户预定义的流水线（pipeline），测试不通过则重新集成，测试通过则开始应用部署。
这种集成方式的覆盖了高质量和可扩展两个方面，但是CRP作为一个通用的持续交付平台，提供的可扩展性有限、而且测试的基础环境种类有限。对于复杂的多技术栈的微服务系统而言，灵活度不足。但是对于系统技术栈统一、持续交付需求简单的客户而言，CRP是一个值得推荐的方式。
基于Hub的持续交付方案
![22.png]()
基于Hub的持续交付方案是最简单的持续交付方案，开发者无需搭建任何服务，可以直接通过在镜像仓库与容器服务中配置触发器的方式完成应用的自动更新。持续交付的本质是如何可扩展、高质量、快速的进行交付。高扩展就要求持续交付系统有良好的流水线（pipeline）的设计，高质量则要求开发者有覆盖充分的测试脚本以及持续交付系统可以标准化的组织这些脚本并运行，而快速则是这三个要素中最简单的，而基于Hub的方案对于很多场景来讲功能上是有缺欠的，但是在速度上是有优势的。用户提交代码后会自动触发容器hub的镜像自动构建，构建完毕后会触发容器服务的自动重新部署实现应用的更新。
这种方案特别适合在测试环境中快速迭代联调的应用场景，虽然在标准的持续集成中测试是必不可少的一环，但是在实际的开发联调的过程中，全量的自动化测试也会给迭代速度带来一些阻碍，因此如果追求快速迭代并且测试的需求不是很强烈的场中，可以考虑直接使用基于Hub的持续集成方案，简单、高效。
尾声
在上文中，我们介绍了三种不同的持续交付方案，开发者可以根据自己的需求选择其中任意一种从零开始进行容器化的交付之路。但是无论哪种方案，都需要进行取舍，选择最符合业务形态的持续交付系统才是最重要的。
