持续交付发布可靠软件的系统方法（交付生态圈）第十五章：持续交付
2019-02-17 本文已影响32人
潘晓华Michael
实现持续交付不仅仅是搭建一些工具，做一些自动化的工作，它依赖于交付过程中的每个人的协作。通过持续交付实践，可以快速且可靠地交付新版本。
配置与发布管理成熟模型
成熟度模型
这个模型的最终目标：
- 缩短生产周期
- 减少缺陷
- 提高软件交付生命周期的可预测性
- 规范合规
- 有效发现和管理软件交付相关风险
- 交付更少缺陷的软件，降低成本
模型指导组织推进持续交付变革，使用戴明环，即计划——执行——检查——处理。
- 使用模型来分析所在部门的配置与发布管理模式
- 选择一个领域集中发力，该领域是你的薄弱环节，痛点所在
- 实施变革。先创建一个实施计划，选择真正感到痛苦的那部分人
- 一旦发生了变化，使用之前创建的验收条件来衡量这些变化是否达到了预期效果。组织所有相关人员召开回顾会议，找出改进点及潜在改进领域
- 重复上述步骤，积累知识，增量改进，推广到整个部门
项目生命周期
团队的组建与磨合常常有以下五个阶段：创建期、风暴期、规范期、运转期、调整重组期。软件也有五个阶段：立项阶段、启动阶段、初始阶段、开发部署阶段、运维阶段。
- 立项阶段：业务分析、业务负责人及涉及部门有关人确立
- 启动阶段：需求收集和分析，规范项目范围和计划。输出有，商务分析报告、概括性的功能与非功能需求列表、发布计划、测试策略、发布策略、架构评估报告 、风险和问题列表、开发生命周期描述、执行上述内容计划描述。包括足以启用项目的细节和最多几个月需交付目标，最合理周期为3个月。
- 初始阶段：一到二周，确保软硬件到位；确保网络、白板、笔纸、打印机、食品等到位；建立好版本控制库；建立一个基本的持续集成环境；角色、职责、工作时间、会议时间上达成一致；为第一周做准备，目标上达成一致；创建简单的测试环境与测试数据；更详细研究预定的系统设计 ；调研识别和缓解分析、开发、测试风险；开发用户故事与需求的待办列表；创建项目结构及构建脚本和一些测试，以验证持续集成环境正常工作
- 开发部署阶段：迭代开发是最基本要求。软件应该一直处于可工作状态；每个迭代都能将软件部署到一个类生产环境中向用户演示；迭代长度不超过两周
- 运维阶段：项目开发部署阶段结束后，一般项目还会继续开发下去，此过程与开发部署阶段差不多
风险管理流程
在项目的各个阶段都要做到风险的识别与预防
- 启动阶段结束时：验证发布策略在关于“创建发布策略”一节（10.2）节讨论过的方面都考虑到了；做好初始阶段的计划
- 初始阶段结束时：确保团队已经准备好开始开发软件了，持续集成环境正常工作，并且有一个类生产环境用于产品代码的部署
- 开发部署风险的缓解：识别、跟踪和管理风险，及时调整。查看部署计划，每次演示后做简单的回顾会议，每日立会作为风险识别的一部分。
常见交付问题和原因
- 构建某个版本花很长时间，而且经常失败。
可能原因：部署过程非自动化；没有足够的硬件；硬件和操作系统配置没有正确管理 ；部署过程依赖于团队无法掌控的系统；没有足够多的人员理解构建和部署过程；测试、开发、分析和运营人员没有充分协作；开发人员没有遵守纪律，通过小步增量的方式的修改保证应用程序一直处于可工作状态 - 缺陷数量持续增加，产品质量下降
可能原因：开发期间，测试与开发没有协作；用户故事在没有全面测试，被测试人员验收，并在类生产环境下给用户演示的情况下标记为“完成”；开发与测试在自动化测试套件开发方面缺少经验；团队不了解哪种类型的测试有效；没有足够的测试覆盖率；系统原来就是一个不可靠的原型。 - 集成周期长，迭代速度慢
可能原因：自动化测试运行时间太长；提交阶段运行时间太长；自动化测试有间歇性失败，还是误报；没人得到许可就回滚别人的提交；没有足够多的人理解持续集成过程 - 环境不一致，导致生产故障
可能原因：UAT和生产环境有差异；没有对生产环境或试运行环境的变更管理流程；在运营、数据管理团队和交付团队间协作不畅；生产环境和试运行环境中的缺陷事件的监管不够有效；应用程序中的指南和日志不充分；应用程序非功能需求测试不充分
