共计 4876 个字符，预计需要花费 13 分钟才能阅读完成。
本节课程为《继续交付办法与实际》，将围绕三个方面开展，为什么要做继续交付、如何做到高效的继续交付以及继续部署。
为什么要做继续交付
01 软件交付流程
想要了解为什么要做继续交付，就要先理解软件交付流程。
传统软件交付流程通常包含四个步骤：
→ 首先业务人员会诞生一个软件的想法；
→ 而后开发人员将这个想法变为一个产品或者性能；
→ 通过测试人员的测试之后提交给用户应用并产生收益；
→ 最初运维人员参加产品或性能的前期运维。
02 传统软件交付的问题和窘境
通过剖析以上流程，能够发现一些传统软件交付流程存在的问题。
①业务人员产生的需要文档沟通效率较低，有时会产生需要文档形容不明确、需要文档变更频繁等问题。
②随着开发进度的推动，测试人员的工作量会逐渐减少，测试工作的比重会越来越大。而且因为测试方法和测试工具无限，自动化测试水平低，无奈很好地把控软件品质。
③实在我的项目中运维的排期常常会被挤占，又因为手工运维繁琐简单，工夫和技术上的双重压迫会导致运维品质难以保障。
因为存在以上问题，所以传统的软件交付常常会呈现开发团队破费大量老本开发出的性能或产品并不能满足客户需要这一双输的场面。由此能够总结出传统的软件交付存在两个层面的窘境：
从体现层来看，传统软件交付存在进度不可控；流程不牢靠；环境不稳固；合作不顺畅等窘境。
体现层的问题其实都是由底层问题引起的，从本源上来说，存在分支冗余导致合并艰难；缺点过多导致阻塞测试；开发环境、测试环境、部署环境不对立导致的未知谬误；代码提交版本凌乱无奈回溯；期待上线周期过长；我的项目部署操作简单常常失败；上线之后呈现问题须要紧急回滚；架构设计不合理导致产生谬误之后无奈精确定位等窘境。
03 继续交付的流程与劣势
通过对传统软件交付问题的剖析和总结，继续交付应运而生，继续交付是一系列开发实际办法，用来确保让代码可能疾速、平安的部署到生产环境中。继续交付是一个齐全自动化的过程，当业务开发实现的时候，能够做到一键部署。继续交付提供了一套更为欠缺的解决传统软件开发流程的计划。
①在需要阶段，摈弃了传统的需要文档的形式，应用便于开发人员了解的用户故事。
②在开发测试阶段，做到继续集成，让测试人员尽早进入我的项目开始测试。
③在运维阶段，买通开发和运维之间的通路，放弃开发环境和运维环境的对立。
继续交付具备以下几个劣势：
①继续交付可能无效缩短提交代码到正式部署上线的工夫，升高部署危险。
②继续交付可能主动的、疾速的提供反馈，及时发现和修复缺点。
③继续交付让软件在整个生命周期内都处于可部署的状态。
④继续交付可能简化部署步骤，使软件版本更加清晰。
⑤继续交付可能让交付过程成为一种牢靠的、可预期的、可视化的过程。
04 麻利开发与 Devops
继续交付依附麻利开发（Agile）和 Devops 两个组件的撑持能够更好地发挥作用。
麻利开发（Agile）次要作用于需要阶段和研发阶段。
Devops 次要作用于开发测试和运维部署阶段。
在这里咱们次要解说一下 Devops 的相干常识。
（1）Devops 的趋势
依据最近的一项个体钻研，DevOps 的市场在 2020 年发明了约 50 亿美元的产值，预计到 2022 年，这个数字将达到约 66 亿美元。随着 Devops 的影响力不断扩大，目前 DevOps 曾经成为软件工程的支流模式。
（2）Devops 效力
Devops 的效力跟公布频率、部署工夫、均匀修复故障的工夫点、部署变更的失败率四个因素严密相干。通常在高效的团队内，公布频率会达到每天屡次公布、部署工夫和均匀修复故障工夫都小于一小时，部署变更的失败率也能维持在 15% 以下。
05 软件交付能力指标
在评估互联网公司的软件交付能力的时候，通常会应用两个指标：
①仅波及一行代码的改变须要破费多少工夫能力部署上线，这也是外围指标。
②开发团队是否在以一种可反复、牢靠的形式在执行软件交付。
目前，国外的支流互联网企业部署周期都以分钟为单位，Amazon、Google 这些头部互联网企业单日的部署频率都在 20000 次以上。国内以百度、阿里、腾讯三大互联网巨头的数据来看，单日部署的频率也达到了单日 8000 次以上。高频率的部署代表着可能更快更好的响应客户的需要。
如何做到高效的继续交付
01 继续交付办法
为了能更好的做到高效的继续交付。在此咱们提供了一个三层叠加的继续交付办法。
首先最上层，继续交付的总指标是价值交付，要为用户交付有价值的内容。
而后第二层蕴含了业务、流程、组织三个维度。
在业务这一维度，次要通过精益、用户故事地图、看板三种形式来缩小业务部门与开发部门的沟通艰难。
在流程这一维度，次要集中于创立一个供开发、测试、运维人员应用的牢靠、可反复的流水线，将这种流水线利用于我的项目的流程中。
在组织这一维度，要求增强团队合作，进步我的项目品质和我的项目改良能力，并且引入了成熟度模型用于评估团队的能力层级。
如果没有技术能力的撑持，仅依附办法和指导思想不足以做到高效继续交付。所以第三层也是最重要的底层是技术层。技术层包含了基础架构和利用架构。基础架构引入了容器集群治理、研发工具平台、继续交付工具链。利用框架引入了浮现式设计、微服务框架还有可能抽离进去的配置化架构。
02 继续交付、继续集成、继续部署的关系
要进一步构建牢靠可反复的流水线，首先就是要理清继续交付、继续集成和继续部署三者之间的关系。
简略来说继续集成和继续部署是继续交付的根底，继续交付包含但不限于继续集成和继续部署。
继续集成是蕴含了代码的编译、近代查看、单元测试工作的集成，尽管继续集成也能形成一条流水线，然而这条流水线并不残缺，而且集成并没有明确的指标。
近几年得益于虚拟机技术和容器技术的迅速倒退，继续部署也逐步变得简略高效，可能使用这些工具疾速将我的项目部署到例如准入环境、预生产环境等等各种环境中。
03 如何构建一个牢靠可反复的流水线
在理清继续交付的关系后，须要通过继续交付来构建一条牢靠可反复的流水线，构建这条流水线的目标是为了让开发人员、测试人员、运维人员能更好的合作实现整个我的项目并上线到生产环境。
通过比照传统流水线和继续交付流水线，能更加清晰地展现出继续交付流水线的弱小。
在传统流水线中，首先代码提交要用过填写表单的模式进行版本申请，而后开发人员在离线环境上手工进行代码编译和单元测试，单元测试实现后须要撰写对应的测试报告文档并且向上提测，在零碎测试环节须要测试人员手动构建和部署测试环境，实现测试之后再次撰写测试报告，并且申请上线，在通过上线审批之后，在线上生产环境须要再次手动构建环境以及进行生产环境的测试，最终实现整体的开发。
在继续交付流水线中，代码合入到骨干之后会间接触发主动编译，主动编译实现之后会进行初步的自动化单元测试、模块测试和零碎测试，在测试过程中继续交付能够主动构建和部署环境。实现零碎测试之后会将问题抛出来，解决实现后再次提测，会自动化的再次进行零碎测试，通过零碎测试之后能够一键操作进行我的项目公布，并进行预上线，在实现预上线后，能够再次进行一键操作实现正式生产环境的上线。
通过两种流水线的比照，能够看进去，继续交付的流水线有显著的劣势。
理论生产中的产品级流水线，能够视为多个模块级流水线的组合，多个模块级流水线组合成为简单的多线并发的产品级流水线，最终能够实现整个我的项目的继续交付。
04 交付流水线落地工具
交付流水线的落地须要依附落地计划和落地工具，目前罕用的落地计划有 GoCD，这是 thoughtworks 的一个产品。还有目前广泛应用的 Jenkins 和 Spinnakeer。
罕用的交付流水线落地工具有效率云平台中的 iPipe 工具，在这个工具中能够依据需要创立流水线，并且将相干内容全都关联到流水线中，这样能够让开发人员、测试人员和运维人员在这个工具中直观的看到产品的状态以及品质状况。
继续部署
对于继续交付整体来说，继续部署十分重要。
01 继续部署计划
容器技术目前是部署中最风行的技术，罕用的继续部署计划有 Kubernetes+Docker 和 Matrix 零碎两种。容器技术一经推出就被宽泛的承受和利用，次要起因是比照传统的虚拟机技术有以下几个长处：
①容器技术上手简略，轻量级架构，体积很小。
②容器技术的汇合性更好，能更容易对环境和软件进行打包复制和公布。
容器技术的引入为软件的部署带来了前所未有的改良，岂但解决了复制和部署麻烦的问题，还能更精准的将环境中的各种依赖进行残缺的打包。
02 部署准则
在继续部署治理的时候，须要遵循肯定的准则，内容包含以下几点：
①部署包全副来自对立的存储库。
②所有的环境应用雷同的部署形式。
③所有的环境应用雷同的部署脚本。
④部署流程编排阶梯式升级，即在部署过程中须要设置多个检查点，一旦产生问题能够有序的进行回滚操作。
⑤整体部署由运维人员执行。
⑥仅通过流水线扭转生产环境，避免配置漂移。
⑦不可变服务器。
⑧部署形式采纳蓝绿部署或金丝雀部署。
03 部署档次
部署档次的设置对于部署治理来说也是十分重要的。首先要明确部署的目标并不是部署一个可工作的软件，而是部署一套可失常运行的环境。
残缺的镜像部署包含三个环节：Build – Ship – Run。
Build 跟传统的编译相似，将软件编译造成 RPM 包或者 Jar 包。
Ship 则是将所需的第三方依赖和第三方插件装置到环境中。
Run 就是在不同的中央启动整套环境。
制作实现部署包之后，每次须要变更软件或者第三方依赖、插件降级的时候，不须要从新打包，间接更新部署包即可。
04 不可变服务器
在部署准则中提到的不可变服务器准则对于部署治理来说十分重要。不可变服务器是技术逐渐演变的后果。
在晚期阶段，软件的部署是在物理机上进行的，每一台服务器的网络、存储、软件环境都是不同的，物理机的不稳固让环境重构变得异样艰难。
起初逐步倒退为虚拟机部署，在虚拟机上借助流程化的部署能较好的构建软件环境，然而第三方依赖库的重构不稳固为整体部署带来了艰难。
现阶段应用容器部署岂但继承和优化了虚拟机部署的长处，而且很好的解决了第三方依赖库的重构问题，容器部署就像一个集装箱，间接把所有须要的内容全副打包进行复制和部署。
05 蓝绿部署和金丝雀部署
在部署准则中提到两大部署形式别离为蓝绿部署和金丝雀部署。
蓝绿部署是指在部署的时候筹备新旧两个部署版本，通过域名解析切换的形式将用户应用环境切换到新版本中，当呈现问题的时候，能够疾速的将用户环境切回旧版本，并对新版本进行修复和调整。
金丝雀部署是指当有新版本公布的时候，先让大量的用户应用新版本并且察看新版本是否存在问题，如果呈现问题，就及时处理并从新公布，如果一切正常，就稳步的将新版本适配给所有的用户。
06 服务形容
服务形容要实现的指标是当软件部署到不同的环境中时，通过服务形容来躲避环境配置的差别。
在服务形容中，通常会对不同的环境下所需的配置进行形容，例如所须要的 CPU、内存、网络等。当理论部署的时候，如果呈现环境差别，调度工具就能够依照服务形容的配置发放资源，使环境可能失常运行。
07 流程管制
在部署阶段，为了避免意外问题的产生，会在一些环节退出人工审核。例如在灰度公布工具中，就会先对线上机器进行分组部署，而后由人工去分组查看，如果没有问题，就进行下一组的部署，如果呈现问题，人工就能够及时的进行回滚操作，防止问题扩充到更多地线上环境中。
08 数据度量和剖析
在实现继续部署或继续交付之后，须要联合多个维度的数据对我的项目整体的研发效率和部署效率进行剖析。例如通过交付工夫周期的长短变动来反映流水线为团队带来的价值。再比方通过筛选和展现团队的相干数据，不便团队来进行决策。还有通过环比汇总数据来剖析变动的趋势。零碎也会通过数据的主动剖析和异样报表监控一些要害指标，一旦要害数据呈现问题，零碎可能及时分割要害人员关注。
通过以上的例子可能发现，继续交付与量化驱动改良是密不可分的，团队可能在度量中发现问题，在度量中看到提高。继续交付就是这样一个不断改进一直优化的过程，通过数据能够量化产出并且指引团队找到痛点并且进一步的深入改良。
点击进入理解更多技术资讯~~