上篇文章学习了DevOps四大知识体系的“敏捷管理”(Scrum框架)、“精益管理”（精益看板），今天继续“持续交付”的学习。
首先还是来了解下持续交付的定义。
持续交付（英语：Continuousdelivery，缩写为CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁，这种方式可以减少软件开发的成本与时间，减少风险。 ——摘自 百度百科
从这段定义中，可以看出持续交付的的三个特点：生产短周期、稳定发布、持续发布。
从这三个特点延申来看，整个持续交付的流程和制造业生产流水线的概念十分相似。制造业中为降低生产成本，提高产品产出速率，提升产品品质，形成了制造流水线的概念。那制造流水线是如何产生的？
20世纪初,美国人亨利.福特首先采用了流水线生产方法。在他的工厂内,专业化分工非常细,仅一个生产单元的工序竟然多达7882种,为了提高工人的劳工效率,福特反复试验,确定了一条装配线上所需要的工人,以及每道工序之间的距离。这样一来,每个汽车底盘的装配时间从12小时28分缩短到1小时33分，并且在整个生产线过程中，可以实时把握产品质量状态，坏品风险大大降低。
再回到信息化生产过程中，过往瀑布式管理项目中程序开发的过程从需求计划→软件代码编程→单元测试→集成测试→开发环境部署→代码发布→运维，周期一般按月计算，并且只能全部开发测试完成后才能交付用户，中间时长跨度大，业务需求变更快，往往最终的成品不能完全满足于客户需求，这就导致很多项目的失败。
如果将生产流水线与软件交付结合在一块，就有了持续交付的流水线，也就是CI/CD/CO（持续集成-持续交付-持续运营）。
要想持续发布除了交付流水线外，还有一个很重要的就是自动化，包括程序代码的自动化构建、自动化功能测试、自动化非功能测试、自动化部署等等。因为交付周期从年度缩短到季度，再到月度，再到周，乃至到天的交付，就意味着原来的代码提交、测试、部署工作的频度也要提升到天。原来只有在程序上线前的部署工作，要在每天内执行，势必要求大量工作的自动化升级，这样才有持续交付的可行性。
根据持续交付的理念，要想实现从代码到运营的全自动化，可借助相应的系统来管理实现。在这里介绍一下基于开源平台的软件，Git：代码版本控制，GitLab：代码仓库，Maven：Java语言构建；Nexus :制品库，JUnit :单元测试，Sonarqube :代码质量扫描，Docker :容器，Harbor :docker 镜像仓库，Jenkins :流程编排，Kubernetes :服务部署。
持续交付过程中，会通过本地开发、集成开发、测试、预发布、正式环境的持续发布快速反馈问题。通过不断反馈来提升代码质量。
本地开发人员单元测试完成后，提交代码到集成环境，则会收到集成反馈的结果；程序集成没有问题，继续向后提交到测试环境，开始对功能性和非功能性进行测试，测试缺陷将直接反馈给开发人员进行处理；测试通过后继续提交到生产环境，部署完成后，通过用户使用反馈程序运行缺陷以及系统优化需求，相应的在重新遍历整个交付流程，调优再行发布上线，达成程序代码质量的管理。
在了解了持续交付相关内容后，企业该如何构建部署持续交付的流水线？第一，对价值流进行建模并创建简单的可工作框架；第二，将构建和部署流程自动化，这也是效果最为明显的一步，实现构建和部署自动化可大幅缩减程序发布的周期；第三，将单元测试和代码分析自动化，有助于开展程序代码以及系统整体的质量分析；第四，将验收测试自动化；第五，将发布自动化。
