借助持续交付建立高效的敏捷研发流程

使用持续交付可以建立稳定的研发流程。但是，你知道其中的原因吗？
一、基础概念介绍  持续交付是什么？
持续集成是一种软件工程的流程，鼓励软件工程师将自己的代码尽早集成到产品代码中，与其他研发工程师共用一套代码的举措。目标在于通过研发过程中快速、频繁的自动化构建过程，及早发现代码中的缺陷或漏洞，避免将集成问题遗留到验收阶段。正如厨师会在烧菜时会尝咸淡，避免菜装盘上桌之后才想起忘记放盐的尴尬。同时，TDD(Test-Driven Development，测试驱动开发)和CA(Code Analysis，代码分析)等内容也逐步加入到持续集成中，共同完成自动化测试和代码质量控制，将项目交付时的风险分摊到了整个研发流程中。
 
传统软件集成流程
传统软件开发流程一般指的是瀑布模型，将软件生命周期划分为制定计划、需求分析、软件设计、程序开发、软件测试和运行维护六个基本活动，并且规定了自上而下相互衔接的固定次序，如同瀑布流水，逐级下落。在瀑布模型中，软件集成这个动作会被放置在程序开发之后的软件测试的初始阶段。由于在程序开发阶段没有进行过软件的集成尝试，程序开发中出现的集成隐患会随着程序开发不断的发展扩散，形成雪球效应，在软件测试前爆发出来。严重的情况可能导致项目长时间停滞。   持续集成流程
相比瀑布模型而言，持续集成强调了频繁的集成和试错，及早发现并解决问题。持续集成将软件集成操作分散在程序开发的整个阶段中，避免了瀑布模型中软件集成的雪球效应。同时频繁的集成操作也有助于及时发现并反馈入库代码的缺陷，部分缺陷在程序开发过程中被修复，降低验收测试中缺陷对项目造成的风险。   
二、为什么流程建立需要持续集成&持续交付 根据成因，软件研发的流程可以划分为两种：以人为核心的流程，以岗位为核心的流程。
 
以人为核心的流程
以人为核心的流程一般通过项目自发形成。大多发生在规模比较小，或者管理比较松散的扁平化团队中。团队没有一套普适的流程和逻辑，成员间依靠相互信任、人际关系或者是领导层的压力，自发的对某一研发目标形成有针对性的研发流程。流程中的每一个节点都和具体团队的成员绑定。这种自下而上形成的研发流程很有可能由于团队人员的变更而产生剧烈突变。一个关键人物的离开，可能导致整个研发流程衰退至振荡期。但是从另一方面讲，自发形成的流程与团队文化紧密关联，会有很强的执行力，每个成员都能按照约定俗成的步骤推进项目。
 
以岗位为核心的流程
以岗位为核心的流程是自上而下建立的一整套研发体系。该方式要求管理层制定研发流程、并且监督整个运行过程。这种对项目关键人员的依赖性会有所降低，允许适度的人力流动。在具体的执行时，管理层能够通过一套严密的手段，对项目的流程进行监控，保障其顺利执行。一旦出现任何不符合项目规定流程的行为，都会被行政干预进行修正。同时，也会针对流程的运作进行监控、分析、改进。在这期间，如果出现任何的行政干预减弱的情况，虽然项目可以按照惯性执行下去，但是既定流程的执行可能会因为得不到足够的行政支撑，出现一系列的衰退现象，最终通过项目产出和过程数据体现出来。
 
用持续集成&持续交付固化现有流程
 
通过两种流程的形成方式，我们可以发现，不管是自下而上自发形成的以人为核心的研发流程还是自上而下以岗位为核心的研发流程，都很难通过一种比较便捷高效的手段彻底完成对流程的固化操作，更不用提对固有研发过程数据的进行收集整理分析的能力。
 
持续集成并不是软件流程，而是软件集成的一种类型。在含有持续集成的流程中，工程师借助于相关的工具将软件集成流程通过自动化的技术手段固化。任何针对流程的调整都需要经过审批、开发才能进入研发环境中。在以人为核心的研发流程中引入持续集成，会将约定俗成的集成流程固化至持续集成的系统中。集成工作从某个具体的研发人员手里转交给计算机自动完成，降低项目内人员的耦合。在初期，由于团队内部对流程和集成工具的理解问题，可能会对项目造成一定的影响。当持续集成方式稳定后，团队中与手动集成相关的人力资源会被释放出来，回到本职工作中。在岗位为核心的团队中，研发流程会从行政干预转向技术干预。即使行政干预减弱的情况下，技术干预依然保证了软件研发流程的正常运作。
 
随着持续集成深度集成到项目中，原有的集成方式会逐步被废弃、遗忘。一些新的理论，流程，方法等内容会被加入到持续集成环境中。最终，持续集成会将研发和运维团队打通，形成持续部署，甚至持续交付。而此时，原有的手工集成方式会受到复杂度，授权等影响，完全不适合研发团队。团队的研发流程会跟持续集成解决方案紧密的结合。