2022-02-16.1.1 软件交付

---

---

一、软件交付过程中的反模式

1. 手工部署软件
   主要表现：具备详尽的部署文档、部署完成后需要手工测试验证程序是否正常运行、部署的时间比较长
   缺点：人工部署的过程不受控，部署文档维护费力，过度依赖具体专职部署专家

2. 开发完成后才像类生产环境部署

3. 生产环境的配置需要手工管理等

二、持续交付的目的

让软件发布成为低风险、频繁、廉价、迅速且可预见的活动。
【精益思想】：聚焦于消除浪费、减少成本
【频繁发布的目的】：使得每个发布版本之间的差异变小，大大减小发布相关的风险，也可以加快反馈速度（指的是发布过程中的反馈）。
【反馈流程的含义】：以完全自动化的方式尽可能地测试每一次变更，包括以下检测：单元测试成功、满足质量标准（测试覆盖率等度量项）、验证测试成功、通过探索性测试
要建立快速反馈机制，对信息进行广播，让所有人员包括开发、测试、运维都要参与到这个反馈流程中

三、软件交付的原则

1. 为软件的发布创建一个可重复且可靠的过程（具体表现为2、3两点）

2. 将几乎所有的事情自动化，不包括探索性测试

3. 把所有的东西都纳入版本控制，存入某个可控制版本的存储库中国，如GIT，包括需求文档、测试脚本、测试用例、配置升级回滚脚本等

4. 提前并频繁地做让你感到痛苦的事情，即持续改进
   这是一条启发式的原则，在持续改进的过程中要分配好时间，分目标进行改进直到不再痛苦

5. 内建质量（尽早发现缺陷）
   所有的原则都是为了尽早发现缺陷，因此交付团队必须执行铁一般的纪律，一旦发现缺陷，就要马上着手修复

6. DONE意味着已发布交付
   对于某个功能或者用户故事，不是开发完成就算DONE了，而是交付给用户以后才算DONE

7. 交付过程是每个成员的责任
   与DevOps运动的核心原则一致：为了更加快速且可靠地交付有价值的软件，鼓励所有参与软件交付整个过程中的人进行更好的协作。

8. 持续改进
   戴明环（PDCA）：计划-执行-检查（回顾）-处理

【关键】关键在于组织的每个人都要参与整个过程，如果只是在自己角色的内部进行反馈环，而不是在整个团队范围内进行的话，就会产生一种顽疾：以整体优化为代价的局部优化，最终导致互相指责