软件工程基础_软件工程核心领域

从公众号转载，关注微信公众号掌握更多技术动态

---------------------------------------------------------------

一、什么是软件工程

1.定义

最开始：为研究和克服软件危机而生；

官方定义：讲系统化、规范的、可度量的方法用于软件的开发、运行和维护的过程。

抓住定义的本质：用工程化方法去规范软件开发，让项目可以按时完成，成本可控、质量有保障。

2.软件工程的核心

软件工程 = 工具 + 方法 + 过程

• 过程：在软件项目的生命周期内，要遵循的步骤。

• 方法：过程中的每个步骤要如何进行。

3.什么是工程方法

有目的、有计划、有步骤地解决问题的方法就是工程方法。

• 想法：定义问题、研究可行性、检查是否有可行的解决方案。

• 概念：用图纸、草纸、模型等方式，提出一些概念性的解决方案。

• 计划：如何实施。通常包含人员、任务、时间、依赖关系和预算等的资源分配。

• 设计：将解决方案进一步细化。设计整体架构、划分功能模块。

• 开发：将设计方案变现。

• 发布：最终结果的呈现。

二、过程指导框架——瀑布模型

1.瀑布模型的引入

边改边写（Code And Fix）模型无法满足复杂软件项目的原因：

• 整个开发过程不可控，基于这种开发模式做计划太难

• 项目人数上升后难以有效分工协作

• 缺少对需求的有效分析，容易导致后期返工

• 没有有效测试，难以保证程序质量

基于此，借鉴建筑工程提出了瀑布开发模型。

2.瀑布模型定义

瀑布模型将项目划分成六个主要阶段：

• 问题定义及规划：需求方和开发方共同制定开发目标，可行性研究。输出【需求文档】和【可行性研究报告】。

• 需求分析：对需求方提出的需求进行详细分析。输出【需求分析文档】。

• 软件设计：根据需求分析的结果，对整个软件系统进行抽象和设计，包含架构设计、数据库设计等等。输出【框架设计文档】。

• 程序编码：将架构设计和界面设计的结果转换成计算机能运行的程序代码。输出【可运行程序】

• 软件测试：对可运行的结果对照需求分析文档进行测试。输出【测试报告】

• 运行维护：正式投入使用后，需要继续维护，修复错误，增加功能。输出【使用说明文档】

瀑布模型的出现，解决了几个重要的问题：

• 让软件开发过程有序可控：各阶段任务十分明确。

• 让分工协作变成可能

• 质量有保障

3.优缺点

(1)优点

• 简单易行

• 可以按照阶段检查，及时发现问题

• 前一个阶段完成后，就可以重点关注下一个阶段

• 有很好的分工协作

• 对质量有保障

• 对着阶段来搞，是会非常清晰的。

(2)缺点

• 不能及时响应需求变更。越到后期变更代价越大

• 最后阶段才能看到结果

• 工作量分布不均衡：前期，开发测试无法参与，后期开发测试又特别忙碌

• 前期进度受阻，会一直压缩后续阶段时间，导致延期或影响质量。

4.衍生模型

瀑布模型提供了一个基本模板，但是在不同的实际场景下，完全套用并不适用。在瀑布模型的基础上，衍生了几个代表性的模型。

(1)快速原型模型

场景：解决客户需求不明确和需求多变的问题。

定义：先迅速构建一个可运行的软件原型，然后收集用户反馈，再反复修改确认，是开发出的软件能真正反映用户需求。

优点：

• 能快速对用户的反馈和变更作出响应

• 注重和用户的沟通

缺点：质量没有保障

快速原型模型主要是为快速确定用户需求，不一定是最后交付的，所以实际软件项目中对原型的处理有两种策略：

• 抛弃策略：在确认完需求后，抛弃原型，实际开发阶段重新开发所有功能。

• 附加策略：在原型的基础上，不断完善，增加新功能新需求，直到达到交付要求。

(2)增量模型

场景：适用于需求比较清楚，能模块化的软件系统，并且能按模块分批次交付。

定义：将待开发的软件系统模块化，在每个小模块的开发中，应用小瀑布模型。

(3)迭代模型

场景：按照时间来拆分项目，看单位时间内完成的功能。

定义：每一个迭代结束时，要完成一个可以运行交付的版本。

5.如何选择过程模型

• 以确认需求为主要目的的项目，不用花太多时间在代码质量上，低成本、高效最重要

• 一个高风险的项目，采用螺旋模型，出现问题及时止损。螺旋模型就是基于增量模型或迭代模型进行开发，每次交付进行风险评估，缝隙过大马上停止开发。

• 一个很长时间加班加点，却一直没办法上线，导致士气低落的项目，可以改成增量模型，然后逐步迭代。

三、过程指导框架——敏捷开发

瀑布模型太重型，周期长，响应慢，因此产生了敏捷开发

1.什么是敏捷开发

敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

(1)软件工程中必不可少的四个阶段，敏捷开发的做法

• 需求分析：建立一个个用户故事

• 架构设计：每个迭代中只做一部分需求，渐进式架构设计。

• 质量保证：自动化测试，开发的同时编写单元测试和集成测试代码。

• 发布部署：持续集成。

(2)敏捷开发和迭代模型的区别

• 没有严格的阶段划分

• 节奏恒定，产品相对稳定，需求未完成不影响发布

2.敏捷开发方法——理论

• 团队成员之间要紧密协作，客户也要自始至终深度配合

  • 定期会议：了解进度与开发问题

  • 知识共享：开发技术学习资料共享

  • 代码共享：代发集中在版本管理工具中

  • 代码审查：对于代码的改动相关人员需要进行代码审查

• 不断反馈和调整

  • 需求调整：在产品真正落地前，不断根据客户要求快速响应需求变化。

  • 功能调整。收集客户反馈、用户反响，来不断调整和优化软件功能。

  • 代码重构。开发过程不断的重构代码，保持代码清晰、内聚、整洁。

• 保持软件可用：先做一个简化功能版本出来，让用户有软件可用，之后再逐步添加更多功能，而非一步到位。这样还有利于不断收集用户反馈和需求，并及时调整开发方向。

• 短迭代，增量发布：频繁交付新的软件版本

• 有一定比例的自动化测试代码，有好的源码管理和持续集成环境。

3.敏捷开发方法——实践

(1)一切工作任务围绕Ticket开展

(2)基于Git和CI的开发流程

主要是解决两个问题：

• 代码不稳定：适用Git的分支管理和灵活的权限控制，可以提高代码的稳定性。具体方法由代码审查和自动化测试。

• 部署太麻烦：CI自动部署

(3)部署上线流程

在流程上对上线部署进行控制：

• 不再部署程序代码，而是Dockers的Image，每次代码合并后CI自动生成新的Image，测试也是基于Image测试

• 部署生产环境前，现在内部的测试环境充分测试

• 部署生产环境前，需要审批确认，有Ticket跟踪。

• 部署时，先部署一部分，监测正常后再全量部署。

• 整个过程都有监控报警，出现问题及时回滚。

(4)每日站立会议

站立会议主要是为了高效沟通反馈，一般控制在半小时内。站立会议的一般流程：

• 成员轮流发言：介绍昨天任务内容，今天计划内容，工作障碍。会议主持者要及时打断偏离主题的问题，建立问题停车场。

• 检查最新的Ticket：检查新增的Ticket，甄别优先级。

• 停车场问题：针对之前来不及讨论的问题进行讨论，能在会议时间解决的立马解决，不能解决的另外组织会议或私下讨论。

4.实践示例

人员：4个程序员（至少一个资深，有架构能力），1个产品经理，1个测试，1个项目经理。

分工：.

• 产品经理：写需求设计文档，将需求整理成Ticket，随时和成员沟通确认需求。

• 开发人员：每天从看板上按优先级从高到低领取Ticket，完成日常开发任务。

• 测试人员：测试已经部署到测试环境的程序，发现bug，提交Ticket。

• 项目经理：保障日常工作流程正常执行，让团队成员可以专注工作，提供必要帮助，解决问题。

每周一个sprint：

• 周一：部署生产环境

• 周二：迭代回顾会议，总结上个sprint。团队成员讨论本轮迭代中什么做得对，什么做的不对，这类会议应该花费很少的时间，并且只讨论上一次迭代的内容。

• 周四：迭代规划会议，计划下个sprint工作。在会议召开前必须完成两项任务:评估可选择任务的开发时间、确定任务的业务价值。会议的节奏应该足够快，简明扼要讨论各个候选任务，然后决定是选择还是放弃，会议在每个任务所花的时间应该限制在5到10分钟，如果需要更详细的讨论应当另选时间，挑出团队中的一部分人进行就可以。

• 周五：分支切割

• 每周轮值：鼓励发挥每个成员的主动性

其中迭代规划会议中，需要对大家一起评估Ticket，可参考的流程如下：

• 会议组织者阅读Tikcet，同时询问大家对内容是否存在疑问。

• 大家一起讨论Ticket，确保充分理解Ticket

• 每个成员在心中对Ticket进行工作量估算，评分。

• 会议组织者确保同时确认估算结果。

• 如果估算存在分析，最高分和最低分各自说明理由，讨论达成一致。

四、软件项目管理金三角

    了解了软件工程的核心，掌握了工程思维，实践中对软件项目的管理需要建立理性的认知，必要时进行合理取舍。

软件项目中有一个平衡关系：

• 软件质量：产品的质量，客户满意度

• 范围：需要实现多少功能

• 实践：多久可以完成

• 成本：花多少钱

    软件工程的目标是要构建和维护高质量的软件。质量高于一切，需要妥协的时候，应该在时间、成本、范围三者之间寻求平衡。

    瀑布模型的范围是固定的，时间和成本是变量。出现不能如期完成进度时，通常选择加人或加班。

    敏捷开发中，时间和成本两条边时固定的，范围是变量。所以在每个sprint开始之前的迭代规划会议十分重要。

五、OPS

1.配置管理

某些可变因素，如红包皮肤等等，做成动态配置化

(1)常见的配置方式

• 源代码中的常量 ：它的特点是定义和使用方便，且只对开发人员友好，每次变更的时候，都需要改动代码。

• 代码中的配置文件 ：配置与代码的解耦。

• 环境配置文件和环境变量：对于不同的环境，虽说代码 是同一份，但是可以通过不同的环境配置文件和环境变量，让代码执行不同的逻辑。

• 运行参数：一个应用可以配置 一个参数

• 配置管理服务：配置管理是从整个系统的层面上抽取并统一管理配置项的方式。通常来说，这样的配置管理系统会 被包装成一个服务，当然，也有少数是单纯放到数据库的某张表里，不过这种数据库访问层 面的耦合通常并不推荐。

(2)配置的层级关系

    资源文件，本质上也算是代码的一部分，通过合理的设计，可以让资源文件具备编程语言代 码一般的继承关系。

conf/rules.conf conf/CN/rules.conf conf/CN/Zhejiang/rules.conf conf/US/rules.conf

conf 目录下，rules.conf 文件就像是基类，存放了默认的规则配置；下面的 CN 目录下的 rules.conf 则存放了中国区的增量配置，就像是子类，里面的配置项优先级高于“基类”的 配置，起到一个有选择性地覆写的作用；而再下面的 Zhejiang 目录下的 rulels.conf 则表 示浙江省的规则配置，优先级更高。

(3)规约优于配置

    系统和配置的用户会建 立“隐性的契约”，通过遵从一定的规则，比如命名规则，达到自动应用配置的目的。

(4)配置模板

对于某些复杂或灵活的软件系统来说，配置会变成实际上的 DSL（Domain Specific Language），复杂程度可以不亚于一门编程语言写的代码。于是，有一种常见的帮助使用 者理解和修改配置的方法就出现了，它就是创建配置模板，写好足量的配置默认值和配置说 明，这样使用者就可以复制一份模板，并在其之上按需修改，比如 Nginx 的配置模板。

2.项目部署

(1)集群部署

集群带来了无单点故障的好处，因为无单点故障，是保证业务不中断的前提。但是，每当有 bug 修复，或是新版本发布，就需要将新代码部署到线上环境中，在这种情况下该怎样保证不间断地提供服务呢？

①重建（Recreate）部署

旧版本停止，新版本启动。存在停机时间的，因此很少采用

②滚动（Ramped）部署

旧版本缓慢地释出，并逐渐被新版本替代。这是最常见的内部 服务的部署方式。对于一般的系统，部署会按照 50% - 50% 进行，即将部署分为两个阶段。第一个阶段， 50% 的服务器保持不动，另 50% 的服务器部署新版本；完成后，在第二个阶段，将这 50% 的老版本给更新了，从而达成所有节点的新版本。对于流量比较大的服务，也有采取 33% - 33% - 34% 这样三阶段进行的。

滚动发布则是在金丝雀发布的基础上进行的改进和优化，第一次也是使用金丝雀发布，后续则使用多批次的形式发布剩余实例，每次批次之间会进行观察，如果有问题，再进行回滚。滚动发布会比较平滑，可以将风险控制到最小程度。它虽然改进了金丝雀发布，但整体发布时间会比较长，回退时间也会更慢，整体流程也更为复杂，适合有一定发布工具研发能力的大公司。

③蓝绿（Blue/Green）部署

    在旧版本不停机的情况下，新版本先完成部署，再将流量从 旧版本导过来。这也是非常常见的，这种部署的好处是，可以有充分的时间，对部署了 但未上线的新版本做全量的测试，在线下确保没有问题了之后再切换线上流量。

    在蓝色环境中进行操作，即部署新版本应用，并进行测试。如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝色环境了。如果运行良好，就可以删除旧版本使用的资源。如果运行出现了问题，你可以通过负载均衡器指向快速回滚到绿色环境。

• 当切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题；

• 有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务停止的；

• 需要提前考虑数据库与应用部署同步迁移 /回滚的问题；

• 蓝绿部署需要有基础设施支持

• 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险

④金丝雀（Canary）/灰度发布部署

    先导入少量的用户访问新版本，在验证正常后再逐步扩展到所 有机器。这种部署也较为常见，最大的优点是它非常“谨慎”，可以逐步地扩展影响用 户的范围，对于一些用户量非常大的业务，这种方式相对比较稳妥，可以不断观察使用 情况和流量数据，在部署环节的任意时间做出适当调整。灰度发布／金丝雀发布由以下几个步骤组成：

• 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。

• 从负载均衡列表中移除掉“金丝雀”服务器。

• 升级“金丝雀”应用（排掉原有流量并进行部署）。

• 对应用进行自动化测试。

• 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。

• 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

金丝雀发布成本较低，只需要一个实例即可降低新版本存在的风险，适合缺乏足够的发布工具研发能力及成长型的小公司。但是，金丝雀发布也有缺点，当升级全部剩余实例时，如果流量过多，可能会导致服务中断。

⑤A/B 测试（A/B Testing）部署

导入特定用户到新版本代码。

⑥影子（Shadow）部署

新版本接收实际的发往老版本的源请求的拷贝，但是并不干预源 请求的处理和响应本身。

(2)数据和版本的兼容

在应用部署的实践过程中，程序员一般不会忽略对于程序异常引发服务中断的处理。比如 说，新版本部署怎样进行 Sanity Test（对于部署后的新版本代码，进行快速而基本的测 试），确保其没有大的问题，在测试通过以后再让负载分担把流量引导过来；再比如说，如果新版本出现了较为严重的问题，服务无法支撑，就要“回滚”（Rollback），退回到原 有的版本。但是除了要考虑程序，还要考虑数据，特别是数据和版本的兼容问题。数据造成的问 题更大，单纯因为程序有问题还可能回滚，但若数据有问题却是连回滚的机会都没有的。

某 Web 服务提供了数据的读写功能，现在在新版本的数据 schema 中增加了新的属 性“ratio”。于是，相应的，新版本代码也进行了修改，于是无论老数据还是新数据，无 论数据的 schema 中有没有这个 ratio，都可以被正确处理。但是，老代码是无法顺利处理这个新数据加入的 ratio 属性的。在采用滚动部署的过程中， 新、老版本的代码同时运行的时候，如果新代码写入了这个带有 ratio 的数据，之后又被老 版本代码读取到，就会引发错误。

因此，从设计开始，我们要就考虑数据和版本的兼容问题：

• 既要考虑新代码版本 + 老数据，这个是属于大多数情况，程序员一般不会忘记；

• 还要考虑老代码版本 + 新数据，这个很容易遗漏 ，出问题的往往是这个。

解决办法就是引入一个新版本 V2 和老版本 V1 之间的中间版本 V1.5，先部署 V1.5，而这个 V1.5 的代码更新就做一件事，去兼容这个新的数据属性 ratio ——代码 V1.5 可以同时兼容数据有 ratio 和无 ratio 两种情况，请注意这时候实际的数据 还没有 ratio，因此这时候如果出了异常需要回滚代码也是没有任何问题的。之后再来部署 V2，这样，如果有了异常，可以回滚到 V1.5，这就不会使我们陷入“两 难”的境地了。但是，在这完成之后，项目组应该回过头来想一想，为什么 V1 的设计如此 僵硬，增加一个新的 ratio 属性就引起了如此之大的数据不兼容问题，后续是否有改进的空 间。

3.测试和发布

(1)CI/CD 和 Pipeline

CI 指的是 Continuous Integration，持续集成，而 CD 指的是 Continuous Delivery，持续交付。它们二者结合起来，通过将工程师的代码变更反复、多次、快速地集成到代码主线，反复编译，执行多种自动化的测试和验证，从而给出快速反馈，并最终达到将变更持续、迅速发布 到线上的目的。

• 持续集成：“持续”指的是从程序员提交了源码开始，相关工具就会自动进行编译、测试等一系列运作，并将结果反馈给程序员。这样，提交代码的程序员很快就会知道刚刚提交的代码有没有问题。“集成”指的是一套操作都是有相应工具支持的，几个工具又集成在一起，构成一个完整的系统。

• 持续交付：开发人员的每一次代码提交，都会自动地编译，并且运行已经定义好的测试程序。测试程序里面就包括性能测试和结果分析。如果分析的结果确认这次代码提交没有性能问题，就成功接受这次提交。否则，就会采取措施通知代码提交者去修正代码；并重复这个过程，直到通过。

• 持续部署：持续部署（Continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到真正的生产环境。持续部署的目标是，代码在任何时刻都是可部署的，并且是可以进入生产阶段的。持续部署的前提是能自动化完成测试、构建、部署等步骤。同时，如果一旦部署了的版本发生不能接受的问题，就需要回滚到上一个版本。这个回滚的过程也需要简单方便，否则会造成非常大的混乱

为了达到持续集成和持续交付，几乎一定会使用一个叫做 pipeline 的工具来将流程自 动化。Pipeline 是一个将代码开发、编 译、构建、测试、部署等等 Ops 活动集成起来并自动化的基础设施。Pipeline 确定和统一了从开发、测试到部署的主要流程，但最大的作用是对劳动力的解 放。程序来控制代码从版本库到线上的行进流程，而非人。因此，如果一个 pipeline 上面 设置太多个需要人工审批的暂停点，这样的自动化就会失去一大部分意义。

整个流程中，版本管理是触发 构建和测试的核心工具，而多层次、不同阶段的测试则是保证整个持续集成和持续交付的关键。

①持续集成价值

持续集成的价值主要有几点：降低代码开发风险，及早发现集成错误，减少手动测试过程，快速生成测试结果，提高程序员和开发团队的安全感。同时，频繁的提交代码，也会鼓励和促使开发人员创建模块化和低复杂性的代码。

做好持续集成的关键在于，快速反馈。(只有 CI 服务器处于绿色的状态才能提交代码；CI 服务器一旦检查出错，要立即修复。)

②工具集 支持持续集成的工具有很多，按照领域分可以有下面几大类：代码版本管理、代码检查、编译连接、功能测试、性能测试、性能分析、代码覆盖率、结果展示等。有些流行的持续集成服务器可以整合这些工具或功能，比如 Jenkins、CruiseControl、Travis 等。我举一个完整持续集成的工具例子。比如一个 Java 开发团队，在开发某项目时用了如下的一系列工具：

• 用 JStyle 来分析 Java 源代码

• 用 Ant 构建运行 JUnit 来进行简单的功能测试

• 用 DbUnit 执行长时间的数据库组件测试

• 用 JUnitPerf 来进行负载和压力测试

• 用 JProfiler 来进行全功能的代码性能剖析

• 用 Selenium 运行基于 Web 的功能测试

• 用 Cobertura 测量代码覆盖率

• 用 CruiseControl 作为服务器来管理持续集成

(2)CI详细流程

持续集成(CI)是构建软件并完成初始测试的过程。持续部署(CD)是将代码与基础设施结合起来的过程，确保完成所有测试并遵循策略，然后将代码部署到预期的环境中。当然，许多公司都有自己的流程，但主要步骤如下。

①代码提交_人工代码审查

人员：开发人员和工程师、数据库管理员（DBA）、基础架构团队

技术：GitHub、Gitlab、BitBucket

过程：代码提交阶段也称为版本控制。提交是将开发人员编写的最新更改发送到存储库的操作。开发人员编写的代码的每个版本都被无限期地存储。在与合作者讨论和审查变更之后，开发人员将编写代码，并在软件需求、功能增强、bug修复或变更请求完成后提交。管理编辑和提交变更的存储库被称为源代码管理（SCM工具）。在开发人员提交代码（代码推送请求）后，代码更改被合并到存储在中央存储库（如GitHub）中的基本代码分支中。

②CI：静态代码分析

人员：开发人员和工程师、数据库管理员（DBA）、基础设施团队、测试人员

技术：GitHub、Gitlab、BitBucket

过程：一旦开发人员编写了代码并将其推送到存储库，系统就会自动触发，开始下一个代码分析过程。想象一下这样一个步骤：提交的代码直接进行构建，但在构建或部署过程中失败了。就资源利用率而言，无论是机器还是人力，这都是一个缓慢而昂贵的过程。必须检查代码的静态策略。SAST（Static Application Security Test）：SAST是一种白盒测试方法，使用SonarQube、Veracode、Appscan等SAST工具从内部检查代码，以发现软件缺陷、漏洞和弱点（如SQL注入等）。这是一个快速检查过程，检查代码是否有语法错误。虽然此阶段缺少检查运行时错误的功能，但这将在稍后的阶段执行。

③CI：build

④CI：测试阶段

人员：测试人员和QA工程师

技术：Selenium、Appium、 Jmeter、SOAP UI、Tarantula

过程：发布一个构建过程一系列自动化测试来验证代码的准确性。这一阶段有助于防止错误到达产品。根据构建的大小，此检查可以持续数秒到数小时。对于由多个团队提交和构建代码的大型组织，这些检查将在并行环境中运行，以节省宝贵的时间并尽早将Bug通知给开发人员。

这些自动化测试是由测试人员（或者称为QA工程师）建立的，他们已经根据用户故事建立了测试用例和场景。他们进行回归分析，压力测试，以检查与预期产出的偏差。测试中涉及的活动有健全性测试、集成测试和压力测试。这是一个非常先进的测试水平。在这里会发现开发代码的开发人员可能不知道的问题。

⑤集成测试：

集成测试是使用Cucumber、Selenium等工具来执行的，其中各个应用程序模块作为一个组进行组合和测试，同时评估是否符合指定的功能需求。在集成测试之后，需要有人批准将该组中的更新集移动到下一阶段，这通常是性能测试。这个验证过程可能很麻烦，但它是整个过程的重要组成部分。核查过程中出现了一些新的解决办法。

⑥负载和压力测试：

负载平衡和压力测试也使用自动化测试工具（如Selenium、JMeter等）来执行，以检查应用程序在高流量环境下是否稳定和性能良好。此测试通常不会在每个更新上运行，因为完整的压力测试是长期运行的。在发布主要的新功能时，将对多个更新进行分组，并完成完整的性能测试。在单个更新被转移到下一个阶段的情况下，管道可能包括金丝雀测试作为替代方案。

(3)CD步骤

①CD：Bake

Bake是指从源代码中创建一个不可变的映像实例，该实例在生产环境中具有当前配置。这些配置可能是数据库更改和其他基础设施更新之类的内容。Spinnaker可以触发Jenkins来执行这个任务，有些组织更喜欢使用Packer。

②CD：部署

Spinnaker将自动将烘焙的映像传递到部署阶段。这是将服务器组设置为部署到集群的位置。与上述测试过程类似，在部署阶段执行功能相同的过程。部署首先转移到测试、阶段，最后转移到生产环境，然后进行批准和检查。整个过程由Spinnaker之类的工具处理。

③CD：验证

这也是团队优化整个CI/CD流程的关键所在。因为现在已经进行了很多测试，所以失败应该很少。但此时的任何故障都需要尽快解决，以便将对最终客户的影响降到最低。团队也应该考虑自动化这部分流程。

部署到生产环境是使用部署策略（如蓝绿部署、金丝雀分析、滚动更新等）执行的。在部署阶段，将监视正在运行的应用程序，以验证当前部署是否正确或是否需要回滚。

④CD：监控

人员：SRE，运维团队

技术：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli

过程：要使一个软件发行版具有故障安全性和健壮性，在生产环境中跟踪发行版的运行状况是至关重要的。应用程序监控工具将跟踪CPU利用率和发布延迟等性能指标。日志分析器将扫描底层中间件和操作系统产生的日志流，以识别行为并跟踪问题的来源。在生产过程中出现任何问题时，都会通知相关人员，以确保生产环境的安全性和可靠性。此外，监视阶段帮助企业收集有关新软件更改如何为收入做出贡献的信息，并帮助基础架构团队跟踪系统行为趋势和进行容量规划。

(4)不同测试的集成

①单元测试

因为单元测试重要的一个因素就是要保证它能够做到白盒覆盖。单元测试要求易于执行、快速反馈，且必须要做到完全的执行幂等性。对于整个持续集成活 动来说，单元测试和其它测试不同，它是和源代码的编译构建放在一起的，也就是说，单元测试执行的失败，往往意味着编译构建的失败，而非一个单独测试过程的失败。

②集成测试

泛指系统组件之间集成起来的功能性测试，但在 Web 项目 中，经常特指的是针对暴露的 Web 接口进行的端到端的测试。它一般被放在持续集成的 pipeline 中，编译构建阶段结束以后执行。

集成测试的成熟程度，往往是一个项目质量的一个非常好的体现。在某些团队中，集成测试 通过几个不同的环境来完成，比如α环境、β环境、γ环境等等，依次递进，越来越接近生产 环境。比如α环境是部署在开发机上的，β环境是部署在专门机器上的测试环境，而γ环境又 叫做“pre-prod”环境，是线上环境的拷贝，连数据库的数据都是从线上定期同步而来 的。

集成测试的过程中，一个很容易出现的问题，就是测试无法具备独立性或幂等性。集成测试 的执行，往往比单个的单元测试执行要复杂得多，有独立性要求测试的执行不会出现冲突， 即要么保证某测试环境在任何时间只有单独的测试在执行，要么允许多个测试执行，但它们 之间互不影响。幂等性则要求测试如果执行了一半，中止了（这种情况很常见），那么测试 执行的残留数据，不会影响到下一次测试的顺利执行。

③冒烟测试

冒烟测试最关心的不是功能的覆盖，而是对重要功能或者核心功能的保障。到了这一步，通常在线上部署完成后，为了进一 步确保它是一次成功的部署，需要有快速而易于执行的测试来覆盖核心测试用例。

通常不会有测试放到生产线的机器上执行，但冒烟测试是一个例外，它在新代码部署到线上 以后，会快速地执行一下，然后再进行流量的切换。除了功能上的快速冒烟覆盖，在某些系统中，性能是一个尤其重要的关注点，那么还会划分 出 Soak Testing（浸泡测试）这样的针对性能的测试来。当然，它对系统的影响可能较 大，有时候不会部署在生产环境，而是在前面提到的 pre-prod 的生产环境的镜像环境中。

冒烟测试最容易出现的问题，是用例简洁程度和核心功能覆盖的不平衡。冒烟测试要求用例 尽可能简单，这样也能保证执行迅速，不拖慢整个部署的过程；但是，另一方面我们也希望 核心功能都被覆盖到，许多团队容易犯的错误，就是在产品一开始的时候可以将冒烟测试的 用例管理得非常好，但是随着时间进展，冒烟测试变得越来越笨重而庞大，最终失去了平 衡。

4.环境

• 开发环境：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。

• 测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。

• 生产环境：是值正式提供对外服务的，一般会关掉错误报告，打开错误日志。