目录

前言：系统集成项目管理工程师专业，现分享一些教材知识点。觉得文章还不错的喜欢点赞收藏的同时帮忙点点关注。 

5.5部署交付

5.5.1软件部署

5.5.2软件交付

5.5.3持续交付

5.5.4持续部署

 1.持续部署方案

2.部署原则

3.部署层次

4.不可变服务器

 5.蓝绿部署和金丝雀部署

5.5.5部署和交付的新趋势

---

5.5部署交付

       软件开发完成后，必须部署在最终用户的正式运行环境，交付给最终用户使用，才能为用户创 造价值。传统的软件工程不包括软件部署与交付，但不断增长的软件复杂度和部署所面临的风险， 迫使人们开始关注软件部署。软件部署是一个复杂的过程，包括从开发商发放产品，到应用者在他 们的计算机上实际安装并维护应用的所有活动。这些活动包括开发商的软件打包，组织及用户对软 件的安装、配置、测试、集成和更新等。同时，需求和市场的不断变化导致软件的部署和交付不再 是一劳永逸的，而是一个持续不断的过程，伴随在整个软件的开发过程中。

5.5.1软件部署

       软件部署是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和 激活等活动来保障软件产品的后续运行。部署技术影响着整个软件过程的运行效率和投入成本，软 件系统部署的管理代价占到整个软件管理开销的大部分。其中软件配置过程极大地影响着软件部署 结果的正确性，应用系统的配置是整个部署过程中的主要错误来源。据Standish Group的统计，软  件的缺陷所造成的损失，相当大的部分是由于部署的失败所引起的，可见软件部署工作的重要意义。

（1）软件部署存在着风险，这是由以下原因造成的：应用软件越来越复杂，包括许多构件、版 本和变种；应用发展很快，相继两个版本的间隔很短（可能只有几个月）；环境的不确定性；构件 来源的多样性等。

（2）软件部署过程的主要特征有：过程覆盖度、过程可变更性、过程间协调和模型抽象。已经 提出一些抽象的软件部署模型，用于有效地指导部署过程，包括应用模型、组织模型、站点模型、 产品模型、策略模型和部署模型。

（3）软件部署过程中需要关注的问题有：安装和系统运行的变更管理，构件之间的相依协调， 内容发放，管理异构平台，部署过程的可变更性，与互联网的集成和安全性。

（4）软件部署的目的是支持软件运行，满足用户需求，使得软件系统能够被直接使用并保障软 件系统的正常运行和功能实现，简化部署的操作过程，提高执行效率，同时还必须满足软件用户在 功能和非功能属性方面的个性化需求。

（5）软件部署模式分为面向单机软件的部署模式、集中式服务器应用部署和基于微服务的分布 式部署。面向单机软件的部署模式主要适用于运行在操作系统之上的单机类型的软件，如软件的安 装、配置和卸载；集中式服务器应用部署主要适用于用户访问量小（500人以下）、硬件环境要求  不高的情况，诸如中小组织、高校在线学习、实训平台等；基于微服务的分布式部署主要适用于用 户访问量大、并发性要求高的云原生应用，通常需要借助容器和DevOps技术进行持续部署与集成。

5.5.2软件交付

       传统的软件交付过程是指在编程序改代码之后，直到将软件发布给用户使用之前的一系列活动，如提交、集成、构建、部署、测试等。传统软件交付流程通常包括4个步骤：首先，业务人员  会诞生一个软件的想法；然后，开发人员将这个想法变为一个产品或者功能；经过测试人员的测试 之后提交给用户使用并产生收益；最后，运维人员参与产品或功能的后期运维。传统软件交付流程 可能存在的问题包括以下3个方面。

（1）业务人员产生的需求文档沟通效率较低，有时会产生需求文档描述不明确、需求文档变更 频繁等问题。

（2）随着开发进度的推进，测试人员的工作量会逐步增加，测试工作的比重会越来越大，而且 由于测试方法和测试工具有限， 自动化测试程度低，无法很好地把控软件质量。

（3）真实项目中运维的排期经常会被挤占，又因为手工运维烦琐复杂，时间和技术上的双重压 迫会导致运维质量难以保证。

       因为存在以上问题，所以传统的软件交付经常会出现开发团队花费大量成本开发出的功能或产品并不能满足客户需求的局面。 由此可以总结出传统的软件交付存在2个层面的困境。

（1）从表现层来看，传统软件交付存在进度不可控、流程不可控、环境不稳定、协作不顺畅等 困境；

（2）表现层的问题其实都是由底层问题引起的，从根源上来说，存在分支冗余导致合并困难， 缺陷过多导致阻塞测试，开发环境、测试环境、部署环境不统一导致的未知错误，代码提交版本混 乱无法回溯，等待上线周期过长，项目部署操作复杂经常失败，上线之后出现问题需要紧急回滚， 架构设计不合理导致发生错误之后无法准确定位等困境。

5.5.3持续交付

       经过对传统软件交付间题的分析和总结，持续交付应运而生，持续交付是一系列开发实践方 法，用来确保代码能够快速、安全地部署到生产环境中。持续交付是一个完全自动化的过程，当业 务开发完成的时候，可以做到一键部署。持续交付提供了一套更为完善的解决传统软件开发流程的 方案，主要体现在：

●在需求阶段，抛弃了传统的需求文档的方式，使用便于开发人员理解的用户故事；

●在开发测试阶段，做到持续集成，让测试人员尽早进入项目开始测试；

●在运维阶段，打通开发和运维之间的通路，保持开发环境和运维环境的统一。持续交付具备 的优势主要包括：

●持续交付能够有效缩短提交代码到正式部署上线的时间，降低部署风险；

●持续交付能够自动地、快速地提供反馈，及时发现和修复缺陷；

●持续交付让软件在整个生命周期内都处于可部署的状态；

●持续交付能够简化部署步骤，使软件版本更加清晰；

●持续交付能够让交付过程成为一种可靠的、可预期的、可视化的过程。

      在评价互联网公司的软件交付能力的时候，通常会使用两个指标：一是仅涉及一行代码的改动 需要花费多少时间才能部署上线，这是核心指标；二是开发团队是否在以一种可重复、可靠的方式 执行软件交付。

      ​​​​​​​目前，国内外的主流互联网组织部署周期都以分钟为单位，互联网巨头组织单日的部署频率都 在8000次以上，部分组织达20000次以上。高频率的部署代表着能够更快更好地响应客户的需求。

5.5.4持续部署

      ​​​​​​​对于持续交付整体来说，持续部署非常重要。

 1.持续部署方案

      ​​​​​​​容器技术是目前部署中最流行的技术，常用的持续部署方案有Kubernetes+Docker和Matrix系统两种。容器技术一经推出就被广泛地接受和应用，对比传统的虚拟机技术，其优点主要有：

●容器技术上手简单，轻量级架构，体积很小；

●容器技术的集合性更好，能更容易对环境和软件进行打包复制和发布。

容器技术的引入为软件的部署带来了前所未有的改进，不但解决了复制和部署麻烦的问题，还 能更精准地将环境中的各种依赖进行完整的打包（ 高22上）。

2.部署原则

      ​​​​​​​在持续部署管理的时候，需要遵循一定的原则，主要包括：

●部署包全部来自统一的存储库；

●所有的环境使用相同的部署方式；

●所有的环境使用相同的部署脚本；

●部署流程编排阶梯式晋级，即在部署过程中需要设置多个检查点，一旦发生问题可以有序地 进行回滚操作；

●整体部署由运维人员执行；

●仅通过流水线改变生产环境，防止配置漂移；

●不可变服务器；

●部署方式采用蓝绿部署或金丝雀部署。

3.部署层次

      ​​​​​​​部署层次的设置对于部署管理来说也是非常重要的。首先要明确部署的目的并不是部署一个可 工作的软件，而是部署一套可正常运行的环境。完整的镜像部署包括3个环节：Build-Ship-Run。

●Build：跟传统的编译类似，将软件编译形成RPM包或者Jar包；

●Ship：将所需的第三方依赖和第三方插件安装到环境中； ●Run：就是在不同的地方启动整套环境。

制作完成部署包之后，每次需要变更软件或者第三方依赖、插件升级的时候，不需要重新打 包，直接更新部署包即可。

4.不可变服务器

      ​​​​​​​在部署原则中提到的不可变服务器原则对于部署管理来说非常重要。不可变服务器是技术逐步 演化的结果。在早期阶段，软件的部署是在物理机上进行的，每一台服务器的网络、存储、软件环 境都是不同的，物理机的不稳定让环境重构变得异常困难。后来逐渐发展为虚拟机部署，在虚拟机 上借助流程化的部署能较好地构建软件环境，但是第三方依赖库的重构不稳定为整体部署带来了困 难。现阶段使用容器部署不但继承和优化了虚拟机部署的优点，而且很好地解决了第三方依赖库的重构问题，容器部署就像一个集装箱，直接把所有需要的内容全部打包进行复制和部署。

 5.蓝绿部署和金丝雀部署

1 #include "stdio.h"
2 void main()
3 {
4     int time;
5     for (time=1;time<=10;time++)
6     printf("%d、喜欢的帮忙点赞收藏加关注哦！\n",time);
7 }