|
|
|
|
公众号矩阵

【廉环话】防疫一周年后的IT项目管理思考 --测试、部署、发布

大家好,截至上期,我们有关IT项目生命周期的管理讨论,算是迈过了“雄关漫道真如铁”的阶段,那么后面是否就是一马平川了呢?非也,我们即将进入“是骡子是马,拉出来遛遛”的阶段。下面,让我们趁热打铁一起来讨论测试、部署与发布三个重要环节。

作者:陈峻来源:51CTO|2021-03-24 09:00

【51CTO.com原创稿件】大家好,截至上期,我们有关IT项目生命周期的管理讨论,算是迈过了“雄关漫道真如铁”的阶段,那么后面是否就是一马平川了呢?非也,我们即将进入“是骡子是马,拉出来遛遛”的阶段。下面,让我们趁热打铁一起来讨论测试、部署与发布三个重要环节。

验证和测试

为了确保新的或变更的产品与服务,能够满足既定的要求,我们需要在开发完成后(如果采用的是瀑布式开发),或是开发过程中(如果采用的是敏捷开发),通过服务验证和测试,来确保产品服务的质量。

在开展测试之前,我们应当先进行服务验证。也就是说,为了确保后续的测试活动能够及时、有效地开展,项目组需要与需求方共协商,明确如下关键要点:

  • 概括出目标系统和服务的各项特征。
  • 罗列可能影响用户使用体验的关键点。
  • 明确测试的目标、范围与深度,量化预期的效果。
  • 根据需求文档和设定的优先级,准备相应的测试用例。
  • 定义即将采取的测试工具、方法与步骤。
  • 明确测试中需要涉及到的人员角色和工作量估算。
  • 定义可能调用的软件资源、硬件环境、以及成本开销。
  • 揭示测试过程可能带来的风险。

可见,服务验证环节,主要是通过建立产品服务,在功能上和效果上的相关标准,以圈定出各项测试活动的重点。

如果说服务验证主要关注和设定的是最低要求的话,那么我们在服务测试环节则会更加全面。总的说来,测试应当主要关注待测产品和服务的如下三个方面:

  • 是否满足既定的业务功能和技术需求。
  • 是否能够按需运行,并提供稳定的服务。
  • 既定的服务功能与效果是否能够被重现与交付。

在测试方法上,我们既可以采取传统的手动测试,也可以运用时下流行的自动化测试方法。两者之间的不同在于:

  • 手动测试:测试人员需要针对目标,手动执行每一个测试用例,人工提供不同的结果集,并仔细记录每一个环节的成败率。当然,有时也需要人工进行测试结果的判断。因此手动测试不但费时费力,而且难免会产生人为的疏忽与误判。
  • 自动化测试:测试人员凭借一些能够自动化运行的工具,开展频繁密集的测试(例如:模拟不同的操作系统、以及不同的浏览器,反复登录某个页面,或是输入各种非常规数据),以实现更高的效率、更少的人工、以及更低的出错几率。

根据实际需求方和后续服务验收的相关要求,我们可以按需开展功能性和非功能性测试。其中:

  • 功能性测试包括:单元测试、系统测试、集成测试、以及回归测试。
  1. 单元测试:着眼于待测系统与服务是否符合详细设计中的要求。通过划分出最小的测试单元,我们可以尽快地找出各个模块,以及组件中的明显错误,进而提高单个服务功能项的质量,并减少后期返工的成本。
  2. 集成测试:检查各个服务组件能否协同工作,测试整个系统能否通过成功构建,达到预期的效果。我们可以在此环节发现系统架构与模块之间、模块与模块之间是否存在着API问题。
  3. 系统测试:关注的是作为产品服务的系统,是否符合设计规格说明的要求。我们可以根据在验证环节中制定的测试用例,通过运行整个系统,来测试服务产品的全面功能与综合性能。
  4. 回归测试:在整改了在上述三种测试中所发现的问题之后,我们需要重新进行一轮测试,以确认没有给系统或服务引入新的错误或缺陷。自动化回归测试将大幅降低系统测试、维护升级等环节的成本。有时候为了保证最终用户的满意度,我们甚至需要邀请他们参与进来,共同检测系统或服务的平稳度和易用性。
  • 非功能性测试包括:性能与能力测试、安全性测试、合规性测试、以及运营测试。可以说,此类测试更注重的是,发现系统或服务在某种环境、或临界状态下的反应、以及自身鲁棒性。也就是说,我们在实际测试中,需要模拟在非常规、或非标准化的内、外部场景中,使用待测系统与服务,并收集相关的特征指标。

显然,测试环节离不开测试用例。为了保证测试的覆盖率, 我们可以根据不同的需求场景,设计出如下不同类型的测试用例:

  • 功能性测试用例。
  • 错误输入测试用例。
  • 逻辑与流程测试用例。
  • 物理与运行环境测试用例。
  • 用户接口与界面测试用例。

测试结果应当能够发现被测服务与实际需求之间的差距。针对测试中出现的错误、问题和缺陷,我们可以采取如下通用流程进行处置:

上图中的每一个节点所对应的解释如下:

  • 新建:这是问题或缺陷被首次发现时的初始状态。不过,某些复杂的问题或缺陷可能需要测试人员进一步予以确认。
  • 审核:由测试主管审核该缺陷的真实性,并判断是否属于重复性提交。一旦确认,他们会及时分派给相应的研发人员、或团队接手处理;否则直接“关闭”、或进入下面的“整改”环节。
  • 分析:研发人员受理该缺陷,通过深入分析,以便制定出整改方案。如果该缺陷的优先级不高,或是交付时间较为宽松,则会被设置为“延期”,留到下一个版本再予以修复。
  • 整改:研发人员通过变更管理流程,对问题或缺陷实施修复与整改,并在完成后流转给测试人员。
  • 测试:测试人员针对原有缺陷展开新一轮的测试。如果通过,该缺陷的状态变更为“已修正并关闭”;如果未能通过,则重返“分析”环节;如果循环多次仍无法修复,其状态应被设置为“已知错误”,并最终体现在写给用户的使用说明中。

当然,在测试与整改完成之后,我们应当及时、且彻底地清理系统中残留的测试数据、各类警告信息、以及历史日志等,以便系统或产品能够顺利地流转到后续部署或发布环节。

部署管理

只有完成了上文提到的验证与测试,项目组才能着手将正确的、已授权的、以及有质量保障的软/硬件版本,部署到真实的生产与运营环境。而为了保持“建转运”过程中的产品一致性,我们需要将待部署的组件保存在一到多个安全位置(即,权威媒体库definitive media library)。

从概念上说,产品与服务的部署过程,实际上就是指将新的或变更的软/硬件、文档、流程或任何其他组件,移置生产环境中,实现“服务转换”的过程。常言道“没有规矩,不成方圆。”为了顺利实现部署的目标,我们需要实施如下规范化的管理。

  • 软硬件类型标准化。无论是网络设备、服务器端、用户终端、还是操作系统和应用软件,我们都应事先制定好支持和首选列表。这样一来,在品牌和型号层面上,我们能够大幅降低非兼容性状态,同时也能缩小出错时排查的范围。
  • 安装配置标准化。我们可参照与实施如下关键要点:
  1. 事先设定好硬件设备所对应的机房和机架的物理位置。
  2. 规范网线、电源线的走向、编号、以及色序等。
  3. 在服务器端,预先分配好虚拟硬件资源(包括:CPU、内存、磁盘空间、分区大小等),准备好相应的虚拟机文件,定义代码的上载目录。
  4. 在用户端,统一通过镜像文件,来批量部署操作系统及应用。
  5. 规范应用支撑软件(包括:IIS、Weblogic等)与数据库的部署路径和配置顺序。
  6. 详细罗列出需要用到的账号名称、登录密码、权限属性、以及服务端口号等细节。

有了上述基础,我们便可以运用如下三种方法,来开展实际的部署工作。

  • 大爆炸式部署:这是针对全新系统与服务的最常见部署方式。它不但直接高效,而且成功率极高。不过,如果由于产品的内外部耦合性与依赖关系,阻止了新旧组件的并行使用(如新旧版本不兼容的数据库架构),则需要将新增或变更的组件,一次性部署到所有目标上。
  • 分阶段式部署:一次仅部署生产环境的一部分,按需重复多次,直到部署完成。例如:针对某个新的系统,我们可以选择第一季度在亚洲区的各个分公司实施,第二季度在欧洲区的各个分公司部署。在充分控制好软、硬件兼容性的情况下,我们需要做好新旧系统的共存,又能够给予用户体验和熟悉新系统的时间。与此同时,一旦发现新系统对现有环境产生不良的影响,我们则需要根据事先制定的回退方案,切换回旧的系统。
  • 推拉式部署:通过与服务请求管理的集成,允许用户选择并控制更新的时间。其中:
  1. “推”,是指将新的或改进的服务推送到各个用户终端上,自动触发部署进程。由于带有一定的强制性,所以该方式一般适用于用户数量庞大的关键性服务。
  2. “拉”,是指用户通过主动触发的方式,通过终端向服务器端请求新的或更新的服务,如:病毒签名库的升级包等。由于灵活性较强,因此用户可以在非繁忙时段,自行获取一些非紧急的更新。

在真实的部署过程中,我们通常采取自动与手动互补的方法。毕竟,自动分发新的或更新的服务,不但保持了整体的一致性,而且能够突破时间和空间的限制,减轻了实施人员的重复工作量。不过,对于一些发生在自动部署过程中的错误,人工勘查、判断、以及手动部署的优势就非常明显。因此“自动在先,手动攻坚”的互补模式,可以有效地消除部署覆盖面上的盲点。

如今,各种敏捷管道与工具,让部署更加快速、更加可靠的同时,也让其成为了一个持续的过程,而非一项任务或事件。因此,我们需要通过监控生产环境中的各个组件、恪守实施步骤,以确保每个环节都能够得到平稳的推进。其中,我们可以重点关注如下方面:

  • 持续监控,识别并记录部署过程中出现的任何问题,包括:应用程序的异常闪退,空的引用所抛出的异常,SQL的连接超时等。
  • 跟踪系统与服务的性能指标、以及用户的满意度水平。其中包括:请求的响应时间与效果,成功获取服务的占比,系统的高可用性指标等方面。当然,有些指标的评分也许在部署过程中并不高,但是在部署完成后,凭借着缓存等方面的协助,能够很快恢复到正常的水平。
  • 保持部署实施团队之间的沟通与同步,大家各司其职,及时反馈。

最后,值得一提的是,就云服务的部署而言,如果是IaaS,企业项目组的部署管理会更加灵活自主;而如果是PaaS和SaaS,则通常需要协同云供应商来共同计划与实施部署。

发布管理

从IT项目的发展周期来看,我们只有在技术上完成了测试与部署,在流程上完成了回滚设计,以及在管理上完成了变更申请和批准,方可通过正式发布的形式,告知相关需求方与用户。具体待发布的内容既可以包括各种基础架构、应用组件、更新流程与工具,也可以包括文档与培训。

既然要发布给用户,我们就需要用清晰、规范的版本号,让使用者一目了然,而且能够获取正确的服务版本。在此,我们可以借助业界普遍使用的软件版本控制规则--“主版本号+子版本号+阶段版本号+日期_希腊字母”,来实施管理。其中:

  • 主版本号的累加,发生在整体技术架构出现较大的变动与调整时。
  • 子版本号的累加,发生在服务与功能出现了增加或变化,比如:增加了访问控制与授权、或是自定义的视图等。
  • 阶段版本号的累加,修复了现有服务中的缺陷,或提升了稳定性。
  • 日期:记录的是修改完成的当前日期。
  • 希腊字母:标注的是当前版本处于哪个开发阶段。例如:Base仅为Demo版本;Alpha为内测版;Beta为公测版;RC为已成熟且无缺陷的候选版;Release为最终正式交付版。

与前面讨论的部署环节类似,如果我们需要对现有服务,特别是云端业务进行发布或调整,则可以选用业界常用的“灰度发布”模式。也就是说,在保留一部分用户继续沿用旧版本的同时,让另一部分用户开始使用新的版本或服务。在并行使用期间,我们能够及时地发现问题,限制影响,按需回滚与调整。待用户对于新版本的体验反馈良好时,再逐步扩大发布范围,并最终让所有用户使用新的版本。

当然,我们的发布目的除了是为了告知用户,也需要映射到日常配置与IT资产管理系统中。此处涉及到对于CMDB进行相关配置项(CI)的签出(check out)和签入(check in)等操作。即:

  • 在执行发布之前,先读取系统与服务的当前状态,并锚定之。
  • 在完成发布与部署之后,将软件的最新版本,写入CMDB中已构建的最终软件库(Definitive Software Library,DSL);而将涉及到硬件的更新与安装,映射到CMDB的最终硬件库(Definitive Hardware Store,DHS)中。

该过程不但可以有效地保证应用系统及其服务的可靠性,而且能够为后续的配置管理提供最新的可参考依据。这就是业界常说的“及时更新基线”。

最后值得一提的是,为了简化和统一管理,许多团队会将测试、部署和发布,合并为如下一整套完备的流程予以实施:

小结

至此,我们的IT项目实施进程算是告一段落了。不过,这并非意味着项目的结束。我们将在下期和您继续讨论项目的验收、监控与改进等阶段,及其相关管理实践。

不可否认,本人在IT项目管理方面的各种思考难免挂一漏万,因此我真诚期待您的留言与斧正。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

【编辑推荐】

  1. Windows Server 2012 组策略管理(2016版)
  2. 中国移动公布2月运营数据:5G客户数达1.68971万户
  3. 集群管理系统 Mesos 的设计原理
  4. 云岫行业研究-基于云原生时代的身份安全管理
  5. 四大运营商哪家5G实力强 基站数量和市占率大比拼
【责任编辑:华轩 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

7人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

36人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

229人订阅学习

视频课程+更多

BurpSuite2.0-渗透测试实战

BurpSuite2.0-渗透测试实战

讲师:Margin283人学习过

Asp.Net网站开发技术及音乐网站项目实战

Asp.Net网站开发技术及音乐网站项目实战

讲师:张晨光3906人学习过

Redis 核心原理与实战

Redis 核心原理与实战

讲师:白丁5644人学习过

读 书 +更多

框架设计(第2版)CLR Via C#

作为深受编程人员爱戴和尊敬的编程专家,微软.NET开发团队的顾问,本书作者Jeffrey Richter针对开发各种应用程序(如Web Form、Windows For...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微