原文链接：https://time.geekbang.org/column/104
与绝大多数理论分析一样，影响持续交付的因素也可归结为：人（组织和文化），事（流程），物（架构）
### 组织与文化因素 什么样的组织文化，才是“持续交付”成长的沃土（当然这也是定义好的组织的标准），我把它分成了三个层次： 第一个层次：紧密配合，这是组织发展，部门合作的基础：一般企业都会按照职能划分部门。不同的职能产生不同的角色；不同的角色拥有不同的资源；不同的资源又产生不同的工作方式。这些不同的部门紧密配合，协同工作于共同的目标，就能达到成效。
第二个层次：集思广益，这就需要组织内各个不同部门，或不同职能的角色，跳出自身的“舒适区”。除思考和解决本身职能的问题外，各部门还要为达到组织的共同目标，通盘考虑和解决所遇到问题和困难。这个层次需要增加组织的透明度，需要接受互相批评和帮助。
第三个层次：自我驱动，是理想中的完美组织形式。如果第二个层次能够持续地运转，就会形成自我学习、自我驱动的飞轮效应，并且越转越快，它甚至能自发式的预见困难，并自驱动解决问题。
那么，在形成理想组织的实际执行中会遇到哪些问题呢？
一般软件企业与交付有关的研发部门包括四个：产品、开发、测试和运维。而这四个部门天然地形成了一个生产流水线，所以形成理想组织的第一层次紧密配合，基本没什么问题。
但是，要达到第二层次集思广益的难度，往往就很大。因为，每个部门有自身的利益，以及自己的工作方式和目标：
比如，产品人员和测试人员就是一对矛体：产品人员希望产品尽快上线，而测试人员则希望多留时间进行更完整的测试。
开发人员和运维人员也经常矛盾：开发人员希望能有完全权限，而运维人员却控制着生产的 root。
那么，靠各个部门自己能解决这个问题吗，其实很难。组织的问题，还是需要通过组织变革来解决。通常我们会采用以下三种方案：
1、成立项目管理办公室（Project Manage Office，简称 PMO）这样的监督型组织，帮助持续交付落地；
2、独立建立工程效能部门，全面负责包括持续交付在内的研发效率提升工作；
3、使用敏捷形式，如 Scrum，打破职能部门间的“隔离墙”，以产品的形式组织团队，各团队自行推进持续交付
当然，这三种方案各有利弊,如：
1、成立项目管理办公室，虽然会带来非常强大的项目推进力，但它往往需要通过流程把控进行监督，这样就很有可能把流程变得更加复杂；
2、而独立的工程效能部门，虽然能最大化地去做好持续交付工作，但其研发成本的投入也是需要考虑的，小团队的话，就不太适用了；
3、敏捷形式是比较适合中小团队的一种组织变革方式，但对个人能力的要求也会比较高，而且往往需要一个很长时间的磨合才能见效。
所以，你需要根据当前组织的情况来选择。总而言之，持续交付必须有与其相适应的组织和文化，否则将很难实施
### 流程因素 #### 持续交付对企业和组织改变最多的是流程 持续交付一定会打破的这三类流程是： 1、耗时较长的流程。 2、完全人工的流程。完全人工操作的流程，一般效率低下，且难以保证质量。 3、信息报备类流程。持续交付过程中同样会产生各种信息流，有些需要广播，有些需要定点传送，实施持续交付后，这些信息报备类的流程一定会通过异步消息的方式进行改造。
在持续交付过程中，最难处理的是审批流程，审批往往指的是由人审核和批准，即是一个全人工流程，又是一个信息流转类流程，那么如何打破它呢，有几种思路：
1、审批流程是否确定需要，若能通过系统保证，则可以去除
2、审批流程是否可从事前流程转为事后流程
3、审批流程是否可以被简化
但是，每家公司的流程都不太一样，所以我的这几个思路并不一定是放诸四海而皆准，但我希望你可以借鉴。
### 架构因素 #### 相对于组织文化和流程因素，架构是真正和技术相关的因素，影响持续交付的架构因素，主要有两大部分：系统架构和部署架构
系统架构指系统的组成架构，决定了系统的运行模式、层次结构、调用关系等。通常会遇到的系统架构包括：
1、单体架构，一个部署包，包含了应用所有功能
2、SOA架构，面向服务，通过服务间的接口和契约联系
3、微服务架构，按照业务领域划分独立的服务单元，可独立部署，松耦合
这些架构对持续交付又有什么影响和挑战？
第二，部署架构
部署架构指系统在各种环境下的部署方法，验收标准，编排次序等的集合，将直接影响持续交付的“最后一公里”。
首先，是否有统一的部署标准和方式。在各个环境，不同设备，应用的部署方式和标准应该是都是一样的，可复用的；除了单个应用外，最好能做到组织内所有应用的部署方式都是一样的。
其次，需要考虑发布的编排次序。特别在大集群、多机房的情况下。通常采用金丝雀发布(后续降到灰度发布时，会讲解)，或者滚动发布等灰度发布策略。那么就需要持续交付系统或平台能够支持这样的功能了。
再次，是markdown与markup机制。为了应用在部署时做到业务无损，我们需要有完善的服务拉入拉出机制来保证。否则每次持续交付都伴随着异常产生，肯定不是大家愿意见到的。
最后，是预热与自检。持续交付的目的是交付有效的软件。而有些软件在启动后需要处理加载缓存等预热过程。这也是持续交付所要考虑的关键点，并不能粗暴启动后就认为交付完成了。同理，如何为应用建立统一的自检体系，也就自然成为持续交付的一项内容了。