基于容器服务的持续集成与云端交付（五）- 探究持续交付系统的本质

换个角度看持续交付

在《基于容器服务的持续集成与云端交付》系列中，我们已经讨论了持续集成与持续交付给软件开发带来的变革，介绍了如何从零搭建一个持续交付系统以及在阿里云上面如何实现持续交付。

不过，在这篇文章中，我们会用一个不一样的角度来思考持续交付，到底持续交付给我们带来了什么，在容器的持续交付的场景中还缺少什么。回到本系列第一篇文章中的容器持续交付的流程图：

(点击放大图像)

这张图中描述了一个基于容器的持续交付的流程，它定义了几个阶段，本地开发阶段、持续集成阶段、持续交付阶段等等，规定了在每个阶段中该做什么事情，开发人员、运维人员应该应该承担什么样的任务与责任。

从某种意义上来讲，持续交付不只只是一个技术问题，更多的是探究自动化软件标准化的交付流程的问题，通过技术的手段将软件开发、测试、集成、交付过程中的每个步骤进行标准化，然后再用一个灵活的流水线将不同的步骤串起来。

软件交付和汽车制造的原理是相似的，最早的汽车是纯手工打造的，产量低可靠性差。随着科技的发展，一辆汽车的零件可以由全球各地的公司制造，然后在一个可编程的流水线上快速的组装出来，现在组装一辆汽车只需要几分钟的时间，而这都得益于模块的标准化和可扩展的流水线。同样持续集成效果的好坏取决于标准化的程度与流水线的扩展能力：标准化程度越高、流水线扩展性越好持续交付的能力就越强。下面我们来讨论如何实现或者选择持续交付中的“标准化”与“流水线”

标准化与流水线

对于大多数的企业而言，通常情况下不会投入大量的精力来开发属于自己的持续交付系统，一般会选择开源的持续交付方案或者使用提供持续交付能力的SaaS 服务，例如基于Jenkins 的持续交付方案或者阿里云的CRP 持续交付平台系统等等。

在Docker 还没有兴起的时代，持续集成的方式通常是通过自动化配管工具来实现标准化的，比如Ansible 的playbook、Chef 的Cookbook 等等，但是这些自动化配管工具更倾向于配置的管理与环境的初始化，换言之，自动化配管工具并不是面向交付的标准化而是更倾向于配置管理流程的标准化。

而Docker 的兴起，给我们带来了交付流程标准化的可能性。当所有交付流程都变得标准化后，流水线（pipeline）则可以将不同的交付流程穿起来，实现持续交付的流程。

如何演进持续交付系统

1. 制定合适自己业务形态的标准与流程

持续交付要符合自己的业务场景与形态，我们经常可以在社区中看到不同的持续集成的方案，但是，最开始要做是根据自己的业务形态来执行流程与标准。有了业务场景再去选择合适自己的持续集成方案。比如阿里云容器服务提供基于 Hub 的简单的持续集成方案，提供基于 Jenkins 的开源的持续集成方案也提供基于 CRP 的持续集成的方案。他们分别面向不同的场景、解决了不同的问题。先明确自己持续交付的场景与所需要的能力然后再选择不同的持续集成的方案。

2. 选择一条合适的流水线或者流水线的默认实现

Docker 已经帮我们解决了大部分交付流程中的标准化问题，那么选择一条适合的流水线则尤为重要，SaaS 类的云服务通常情况会提供标准的流水线（pipeline）实现，但是相比而言，基于 DSL 的 Jenkins 的流水线（pipeline）是更为强大的选择。针对于不同的业务，开源的 Jenkins 流水线灵活的程度大于 SaaS 类的持续交付系统的流水线大于固定流程的流水线。

3. 根据业务的需求不断的丰富流水线上的流程

在使用持续集成的过程中，我们会根据业务的形态的变化，不断的在流水线上添加或者删减持续交付的流程。当持续交付的流程被大家认可并遵守的时候，持续交付的能力就会真正的展现出来。通过类似模块化的插拔将不同的组件不同的流程融合在一起，不断的演进，满足不同维度的业务场景与方向。

尾声

还有什么是我们没有讨论的？其实 Docker 给我们带来的不只只是标准化的部分，还有更多的是职责划分的思考，从前从软件的开发到测试之前的部分是开发负责的，而从测试、上线、后期的线上运维都是运维的人员负责的。

不过，软件架构的变革例如微服务的兴起等等会导致运维变得越来困难，从前一个企业只有少量的“巨石”软件系统，运维人员只需要运维少量单一的技术框架的系统即可。但是，现在一个微服务系统可能有几十个模块，每个模块的运行时环境、运维方式都不尽相同，这给运维带来的难度是指数级增长的。

现在越来越多的人在讨论 DevOps 或者 SRE，其实这并不是一个新的职业，更多的是对于开发与运维边界的重新定义。

个人觉得开发人员未来会更倾向于 DevOps 的方向发展，即开发人员中会有更细分的倾向，部分开发人员倾向于线上维护与组件调优而另一部分则侧重软件开发。

而运维人员会更倾向于平台化或者 SRE 化，运维人员会花费跟多的精力在自动化持续交付平台流程的建设与优化、基础设施的建设（监控、日志、扩容）等等。

持续集成与持续交付不仅是提速了交付的流程，更多的是优化了开发人员的职责划分与交付的方式。

个人简介

莫源，阿里云高级研发工程师。在加入阿里巴巴之前，先后在北京天方地圆科技有限公司、微软亚洲研究院任职。现主要负责阿里云容器服务产品的底层服务发现系统、集群管理系统的研发，从事容器的持续交付、持续集成的方案的设计与实现。在云计算、分布式系统、图像识别与虚拟现实方向有多年的开发经验。

感谢木环对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。