软件交付通识

Posted 2023-03-11 小琳猫

软件交付通识

• 摘要
• 写在前面
• 1.软件交付概述
• 2.历史演进
• 3.典型软件交付过程
• 4.具体活动
• 5.10个策略

摘要

本篇博客参考董越老师的《软件交付通识》，对其第一部分内容进行简要总结，以便加深理解和记忆。

写在前面

1）书本导读

这本书介绍了软件交付的概念、目标、历史演进、策略、过程、细分领域、关注点和各个具体过程，并不针对具体的工具、技术、管理方法，更多介绍了概念性的、全面的“软知识”。这些知识由作者的经验汇聚而成，需要较多的亲身实践才能读进去，产生共鸣。

2）其他

正如上面所说，阅读此书需要一定的实践经验，且需要站在项目管理者的层面考虑，因而我读此书时，仅对软件交付相关概念和思想进行了了解，后面具体的过程没有读完。这实际并不能算是一种失败，正如今天阮一峰发布的科技爱好者周刊245期中引入的文摘中有：

“生命太短暂，不能花在那些不值得阅读的内容上面。就算你是一个很爱读书的人，活到70岁最多大概能阅读15000本书，这只占世界最大图书馆美国国会图书馆3800万册藏书的0.04%。我们一生中能够阅读的书籍其实很少。因此，关键技能不是多读，而是跳过那些不值得读的内容。”

若以后有缘再读此书或是多年以后…

1.软件交付概述

1）软件交付过程（Software Delivery Process）：编码之后到软件发布给用户为止的一系列活动，包括如：提交、集成、测试、代码评审、构建、发布上线等

2）软件交付过程的主要内容：①测试（动态的接口测试、UI测试；静态的代码评审、代码扫描；人工测试、自动测试）②提交、集成、联合测试、发布 ③软件形态转换：将源代码编译构建，转换为归档包、容器镜像等形态经过部署得到可实际运行的软件系统

3）软件交付不是按时间阶段或角色划分出来的，只要是做生产环境上的部署、完成软件的发布就属于软件交付过程

4）最终目标：一切为了业务（业务驱动）的成功（访问量、活跃用户数、市场占有率、盈利能力、社会效率、人类福祉）

5）小步快跑：将软件的生命周期划分为定义侧和实现侧，定义侧应定义一个小步伐的目标，实现侧应该快速完成。这是由于需求的不确定性，因而先做一个最小可行性产品MVP（Minimum Viable Product）确定市场、用户需求

6）软件实现侧/交付过程的目标：①较高的产能；②更快的响应速度；③适当的质量；④合理的成本

2.历史演进

1）从软件危机到工程化

2）敏捷

2001年“敏捷软件开发宣言”，去过度工程化

①管理实践：Scrum；②工程实践：单元测试；持续集成

3）精益

①起源于制造业的精益思想：面对VUCA（易变性Volatility、不确定性Uncertainty、复杂Complexity、模糊Ambiguity）的市场，去批量化、减少等待时间，从追求资源效率（单位成本的最大产出）到流动效率（审视创造用户价值的过程是否通畅）

②将精益思想应用于软件开发：精益创业（如何在高度不确定的情况下开创新的产品或服务）“开发-测量-认知”循环，用开发验证需求

③精益软件开发的重要实践：精益看板，将未发布上线的各个特性展现在看板墙上，使其可视化，让团队能够看到每个特性的进展

4）持续集成、持续交付、持续部署

• 持续集成

2007《持续集成：软件质量改进和风险降低之道》

①定义：持续集成是一种软件开发实践，即团队的成员经常集成（特性分支到主干分支、解决冲突）他们的工作，并通过自动化构建（测试）来发现并修复质量问题（本地测试、开发环境测试）

②如何做：版本控制、质量内建（系统交给测试人员之前先由开发人员自测）、自动化（提交自动触发测试流程）、过程可视化、加速

• 持续交付

①定义：持续交付是一种软件开发实践，能够让各类变更（新特性、配置变更、缺陷修复、尝试性内容等）安全、快速、可持续的交付到生产环境中或用户手上

②相比于持续集成的提交集成与开发环境测试相比，持续交付将质量验证工作扩展到整个系统与发布上线，其中融入更多的自动化，使比较频繁的发布上线成为一键式，是持续集成的更进一步。

• 持续部署

持续部署意味着每个通过部署流水线的变更都能动态地部署到生产环境中，相比于持续交付要求测试做到完全的自动化，可理解为持续交付的极致。

• 优点

①早合并、早暴露冲突和错误，早解决；②有利于跟踪进度和提供对进度的感知；③早接近可发布给用户使用的目标

5）DevOps

• 概念

2009 “10+Deploys Per Day:Dev and Ops Cooperation at Flickr” 《DevOps实践指南》

DevOpts标准（中国信息通信研究院的研发运行一体化能力成熟模型）

DevOps运动，强调从组织、流程规范特别是技术上将运维甚至安全（DevSevOps）等纳入进来，打通开发（Dev）、运维/技术运营（Ops）之间的隔阂（开发出新特性并上线 vs 线程运行的稳定性），实现真正的端到端，从用户需求到最终用户端。

DevOps是一组最佳实践，融合了“务虚”和“务实”，既包括组织、流程、文档、乃至文化，也包括自动化构建、自动化测试、自动化部署等技术。基于DevOps的最佳实践，充分运用自动化技术形成了虚拟的、可大量复制的软件生产及发布流水线，无需专门的运维人员，开发人员可以一键触发自动化部署、自动化测试

• DevOps三步工作法

①实现从开发到运维的快速从左向右流动：工作可视化、减少批次大小和等待间隔、内建质量避免向右传递缺陷，持续优化全局目标
②从右到左的每个阶段，应用持续、快速的反馈机制，通过放大反馈环防止问题复发，缩短问题检测周期，实现快速修复
③建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验，主动承担风险，从失败中学习

• 落地实践

①自动化基础设施、共享的版本控制、一键完成构建和部署、特性开关、共享度量统计、即时通信机器人
②尊重、信任、对失败的正确态度、避免指责

6）技术方面的演进

①软件架构：结构化→面向对象→组件、插件、动静态链接库→微服务→软件复用与中台
②部署运行：虚拟机→容器化

3.典型软件交付过程

代码改动积累 → 代码改动提交（到特性分支） → （特性feature）分支改动积累 → （特性）分支改动提交（集成分支dev） → 集成分支改动积累 → 集成分支改动提交（主分支master）→ 发布（release）

4.具体活动

源代码版本控制、构建、构建环境管理、制品管理、部署、运行环境管理、配置参数管理、数据存储结构管理、代码评审、代码扫描、制品分析、单元测试、自动化接口测试、人工UI测试、自动化UI测试、非功能测试（性能与容量、安全性、兼容性、易用性）、生产环境测试

5.10个策略

1）细粒度、低耦合、可复用的架构

①软件架构

②测试脚本和测试数据的架构：数据驱动（测试脚本和测试数据分离）、页面对象模型、业务流程抽象、关键字驱动

③组织架构：小团队（5-9，<15）、低耦合（独立自主）、可复用；特性团队（长期的、具备交付价值所需的各种角色、可以协同完成完整用户价值交付的团队，针对独立产品而非仅是特性分支）；康威定律（组织结构做成什么样子，那么产品系统的架构就长什么样子）

2）小批量持续流动的流程：①大批量带来等待等问题；②短周期、小粒度、减少在制品

3）运用综合手段保证质量和安全

①综合各种测试：人工测试；自动化测试（接口、UI）；开发、生产环境（全链路压力测试、混沌工程、灰度发布、A/B测试）测试；灰度发布、绿蓝部署；分层测试策略（金字塔模型；橄榄球模型）

②左移（开发人员测试）+右移（发布到生产环境再测试）

③测试人员（专业能力测试：探索性测试、安全方面测试）+开发人员（单元测试、单个接口测试、代码评审、结对编程）

④人工测试+自动化测试（需要反复执行、有明确标准和规则的测试，不能完全取代人工测试）

4）自动化（单项活动自动化、流程自动化）与自助化（用户可以方便地自行配置使用，无需专门的运维人员即可一键式地构建、测试、发布）

5）加速各项活动：提高硬件能力；考虑并行；避免重复；只关注增量；使用缓存

6）及时修复：通知及时和精准；优先处理；修不如退；便捷排查

7）完备记录，充分展示：任务及其执行情况（工作项/变更请求管理工具）；日志（构建日志、部署日志、自动化测试报告）；版本和配置信息；制品管理；关联关系；维持单一可信源（Single Source of Truth,SSOT）

8）标准化：规范可重复（构建、发布过程标准可重复，同一源代无论在哪构建结果一致）；方案收敛（同一团队、公司的工具流程方案应一致）；环境一致性（本地开发环境、测试环境Mock挡板、生产环境）

9）协调完成完整功能

10）基于度量的持续改进