Continuous Delivery

前言 标准先行并不是一个新鲜玩意，不过是先制定事实标准，而后使用这些标准约束之后的行为。俗话说得好：“没有规矩，不成方圆”。在这里，我想说一下我认为的标准先行以及与持续交付的结合，希望不会对你产生误导。 为什么需要标准先行 我们可以先不去问为什么，而是反过来看这个问题。假设在我们的产物交付过程中，没有任何的标准，给你自由，会发生些什么问题。在一阵头脑风暴（抽搐）之后，我做出如下假设： 乱象百出，群魔乱舞。不论是正确的还是错误的产出，解释如此。比如，整体代码的可读性和可维护性直线下降；分支来回穿插，Commit 信息奇奇怪怪；开发、测试环境存在混用，测试数据过于随意；部署由心，同一个应用在不用的主机上存放位置可能还不同等等。 过程、阶段性产物不统一，且质量高低不齐，严重影响系统集成与交付。 高效完成，但前提是有着意见一致、理念相同、水平相当的一群人。 在我的假想中，自由带来的有好也有坏。但是我仍认为大部分的时候出现的都是坏的影响，毕竟要寻找到一群志同道合的人一起共事，就已经是一件很不容易的事了，且不说每个人都是单独的个体，其思想与灵魂亦是独一无二的。所以，不管在什么样的情况下，我们都需要制定标准来约束我们的行为。统一标准下的行为造成的影响几乎是一致的，那么即使是排错、修改时也是有迹可循。（在这里不会抬杠标准与自由的取舍，存在即是合理。但是从两者在大部分时候所能产生的影响来看，我会采取强标准，若自由的方式，但这绝非将两者置为对立关系。） 都有哪些标准先行 没有绝对通用的标准，任何的标准都是不同场景下最佳实践的总结，且需要持续的进行优化，是可以传承的宝贵知识集合。之所以扯这么一段话，我只是想说目前还处于实践阶段，但是这并不影响制定相关的标准。使用过 SpringBoot 开发的大佬都知道什么是约定优于配置，我认为标准亦是如此，即标准之上是约定。在这里，我将需要先行的标准分为了如下几个方面： 开发模式与分支策略（含 Commit 规范） 编码规范（Java、JavaScript） API 设计规范 数据库设计规范 环境隔离 部署规范 发布流水线标准 标准先行与持续交付 总结 参考文献 持续交付36讲 说明 我不是在卖课 本文大部分内容来源于极客时间以及网络博文节选，如有冒犯，我先向您道歉，另还请告知我进行处理，谢谢 邮箱：thread_zhou@126.com

前言 在我们日常的划水中，常常听到持续集成、持续部署、持续交付、DevOps，那么这些名词到底是什么意思？对我们的日常工作有什么作用呢？能够提高划水的效率呢？其实对于名词的解释始终还是千人千面，不同环境下必然存在不同的产物，我今天想说一说我自己的理解，希望不会对你有误导。 什么是持续交付 持续交付：（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。 由上可知，持续交付的关注点在于以下几个方面： 短周期 随时可释出 频繁构建 持续交付也可以拆开分析，所谓持续便是一直的频繁的做某件事，有一种开始也是结束，结束也是新的开始的感觉，需要闭环反馈来支持下一个阶段的持续行为；而交付则表示针对当前交付目标释出可行的产物。上面提到的随时可释出和频繁构建很好的体现了持续交付的行为特性，而短周期则是表示每一个阶段的交付过程应该在一个短的周期之内完成，因为短周期意味着快速交付、快速反馈、快速反应并快速的循环反复，而长周期必然会加大一次交付流程的耗时（加大试错成本，无法快速反应），所以这样才能够达到持续交付的目的（随时可交付）。至于什么才是合适的短周期，这个需要结合企业或团队的具体情况（比如项目当前所处阶段、研发人员素质、研发上线流程等）进行考虑。 说了这么多，那么持续交付是以什么样的形式。如何落地到我们日常的工作中的呢？结合美团外卖持续交付分享（美团外卖持续交付的前世今生）和极客时间课程持续交付36讲，我总结了如下的一种描述。（希望不会将你带偏） 关于持续交付，不同的企业、不同的团队站在不同的角度会存在不同的定义，我们可以把持续交付定义为一个产品价值的开发框架（站在企业的角度）、一套软件工程方法论以及许许多多最佳实践的集合。持续交付的落地便是开发框架或软件工程方法论与实际情况的结合的实践（也可以说是最佳实践的排列组合），更详细的实践情况还请接着往后看。 持续集成、持续部署、DevOps和持续交付的关系 持续集成 持续集成：（英语：Continuous integration，缩写CI），是一种软件工程流程，是将所有软件工程师的软件工作副本持续集成到共享主线（mainline）的一种举措。该名称最早由葛来迪.布区（Grady Booch）在他的布区方法中提出，在测试开发驱动（TDD）的实践中，通常还会搭配自动单元测试。持续集成的提出主要是为了解决软件进行系统集成时面临的各种问题，极限编程称这些问题为集成地狱（integration hell）。 持续集成的关注点在于： 频繁集成 有效协作 自动化测试 我们通常会将软件研发工作拆解，拆分成不同模块或不同团队进行编码，编码完成后，进行集成构建和测试。这个从编码到构建再到测试的反复持续过程，就叫做持续集成。由持续集成的定义可联想到版本控制，如 Git，进而可以关联到分支策略（如：Git Flow、GitHub FLow、GitLab Flow），可以说分支策略是持续集成的前置条件。一般情况下，会有一个分支作为集成使用，加上多个特性分支（这里和具体的分支策略强相关，并不是所有团队的都是一样的），当特性分支开发完毕，通过 PR 请求合并到集成分支，此时会触发持续集成工作流程，保证待合并的分支内容是有效的，只有通过持续集成流程验证，才能合并到集成分支。 持续部署 持续部署：（英语：Continuous deployment，缩写为CD），是一种软件工程方法，意指在软件开发流程中，以自动化、频繁而且持续性的，将软件部署到生产环境（production environment）中，使软件产品能够快速的发展。持续部署可以被整合到持续集成与持续交付的流程之中。 持续部署的关注点在于： 自动化的 频繁的 持续性 生产环境 在一些企业的软件部署工作中，仍然存在全人工操作的方式。如果只是单纯的安装部署目的还较为容易（不过繁琐的配置，人工的不规范、不确定性，部署的耗时等都是成本）；而如果是已上线的服务的部署工作（服务更新），此时的涉及面以及受影响的范围就比较大了。就算释出的产物已经可以达到可交付的标准，但是要使得用户真正可用，还需要跨越安全、快速以及稳定部署的障碍。那么是否可以将部署的场景和过程进行抽象，使用统一的、规范的、自动化的方法论和流程来约束和实现部署的过程。而持续部署便是这样的一套方法论及实践工具集，旨在规范部署行为，通过自动化提高部署效率，达到持续部署目的。 持续集成、持续部署与持续交付的关系 当提到持续交付的时候，总能关联到持续集成与持续部署，我也一直傻傻分不清这三者之间有什么区别，是什么样的关系。不过从前面给出的定义和关注点可以知道，持续集成侧重于编码阶段内多人协作产物集成的有效性，持续部署侧重于将产物部署到生产环境，而持续交付则侧重于需要随时可释出；而相同点在于他们三者都推崇持续性，即存在一个反馈的过程，且反馈的结果作为下一阶段持续的支持。 再说到持续集成、持续部署和持续交付之间的关系，这里还有一个比较有趣的地方，那就是在不同的视角下，三者的关系并不一样，这里借鉴美团外卖分享的内容（美团外卖持续交付的前世今生）举例，从研发和产品的角度来分析这三者的关系。 研发视角：我们可以看到大部分研发团队，会从软件研发的角度进行定义，他们将软件的开发步骤拆解为持续集成、持续交付、持续部署，其中持续集成指开发人员从编码到构建的过程；持续交付则作为持续集成的自然延续，指将已经集成构建完成的代码，交给测试团队进行测试的过程；持续部署指将测试通过的软件交付给用户的过程。在研发的视角下，持续交付就是一个承上启下的过程，与持续集成形成了闭环，而又为将来达到持续部署做下了准备。此时持续集成 + 持续交付 + 持续部署便是一条完整的发布流水线。 产品视角：产品团队会站在产品的角度来看，他们认为持续交付，是从需求的 PRD 文档提出来，到用户能够感受这个需求的周期。也就是说，此时持续交付是完整的包含了持续集成与持续部署，但是持续交付涵盖范围是大于持续集成 + 持续部署。并且，此时的持续交付流程本身就包含了一条完整的发布流水线。 借用持续交付36讲中的 发布流水线 示意图 说到这里已经不难看出，影响三者之间相互关系的因素主要在于对于持续交付的定位。在这里先说说我自己的看法，我认为持续交付的核心要义在于：短周期、时刻可释出、持续构建，即在于持续的产出与持续验证，由产出与验证形成闭环，进而相互推动，以达到快速反应，快速实现，持续优化。而短周期便是一次交付过程耗时的预定义，也是对于效率的要求，但一定不是对用人的压榨（去你xxx）。在持续交付中，交付对象不一定就是最终用户，所以千万不要认为一定要做到端到端完整才是持续交付。持续交付是一个周期性、可持续的行为，可以只是研发到测试的闭环，此时于研发而言交付对象是测试团队，交付物为通过持续集成验证的代码；也可以如产品视角一般，从需求的 PRD 提出来到用户能够感受到这个需求的周期，此时交付对象为用户，交付物为可用的产品。 所以持续交付可以只是一套方法论，可以是产品价值开发框架，也可以是一部分流程实践。于我个人而言，我更认同持续交付是一套方法论（兼产品价值开发框架），由此指导持续交付体系的建设。如果你问我持续交付体系实践中使用到的技术是不是持续交付，我会说，在其中使用到的技术或工具只是当前持续交付体系建设的一个组成部分。所以，关于持续集成、持续部署、持续交付三者之间的关系，我认同为：三者相互渗透（可能这个词不是很恰当），并没有绝对的独立。 DevOps DevOps：（是 Development 和 Operations 的组合词），是一种重视“软件开发人员（Dev）”和“IT 运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 传统的软件组织将开发、IT 运维和质量保障设为各自分离的部门，再这样的环境下如何采用的新的开发方法（例如敏捷软件开发），是一个重要的课题。按照从前的工作方式，开发和部署，不需要 IT 或者 QA 支持（跨部门的持之），而现在却需要极其紧密的多部门协作。而 DevOps 考虑的不仅仅是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。...