没有高效的部署流水线，何谈DevOps

什么是流水线

流水线（Pipeline）源自福特，是工业化生产的基石，福特汽车采用流水线生产之后，组装车辆从12.5小时缩短至93分钟，效率提升8倍，这也是福特称霸一时的根源之一。

那流水线能驱动软件效率的提升吗？

2017年的DevOps年度报告中，高效能组织比低效能组织的部署频率高出46倍，而高效能组织都会使用持续交付与流水线的实践。

部署流水线是指软件从版本控制库到用户手中这一过程的自动化表现形式。对软件的每次变更都会经历一个复杂流程才能发布，这一流程包括自动化构建、测试与部署，部署流水线是对这一流程的建模。

为什么需要流水线

作为DevOps的核心工程实践，持续交付驱动着研发、测试与运维的流转，其中部署流水线又是核心中的核心。

1. 流水线贯通研发、测试和运维，在部门墙之间打了一个洞，让价值顺畅流动 2. 流水线将持续交付的核心工程实践和工具链整合起来，包括自动化构建、测试、部署等实践与工具技术 3. 流水线的每个环节都会有反馈，实现完整快速的反馈循环 4. 流水线的每个环节都会设置质量门禁，实现质量的层层保障，实现JKK

流水线的基础

配置管理

配置管理是持续交付的基础，自动化的源头。

源代码的版本控制，可以采用Git,SVN等工具，重点是分支策略的选择。分支策略决定了团队的协作模型和交付速率。 组件的依赖管理，可以采用Maven、Gradle（Java技术栈）等工具，重点是标准化依赖管理，采用惯例优于配置的模式 制品的版本控制和分发，对制品也要做版本控制 环境的版本控制，可以采用Ansible等工具实现基础设施即代码 应用配置，可以采用Apollo或者Disconf实现分布式的应用配置管理 数据配置，重点是DDL和DML的版本控制和执行

持续集成

上图是持续集成的路线图，做好配置管理之后，将构建标准化（目录结构、依赖管理等），再实现构建的自动化。

Jez Humble和Martin Fowler两位持续交付的大神，设计了三个问题，来测试你的持续集成做的怎么样？

1. 是否每位开发者每天都会往主干提交至少一次？ 2. 是否每次提交都触发自动化构建和测试？ 3. 如果构建或测试失败，是否可以在10分钟内修复？

自动化测试

关于自动化测试是一个复杂的话题，不在此展开，重要的一点是，在单元测试推行成本较高的情况下，优先做接口级的自动化测试。

如何实现流水线

流水线实施的步骤

部署流水线在整体上可以划分为提交阶段、验收阶段、部署阶段。关于配置管理、自动化构建、自动化测试、自动化部署、发布管理等，按照前后关系，逐步建设。

太阳系中，所有行星围绕太远运动，是因为太阳有着强大的引力。持续交付和DevOps也一样，由于业务的强大引力，需要我们变得更快，所以分支策略、测试技术、架构、发布策略、基础设施、数据库管理都需要围绕部署频率（业务需要）来运转。

全开源端到端部署流水线