持续交付2.0
2021-05-02 21:27:55 2 举报AI智能生成
持续交付2.0 结合了 敏捷开发、精益创业等思想给出的一系列的原则、方法与实践；DevOps是一种工程文化和实践，旨在统一整合软件开发和软件运维。是一种组织管理的发展趋势；
作者其他创作
大纲/内容
9.持续集成
六部提交法
1.检出最近成功的代码
2.修改代码
3.第一次个人构建
4.第二次个人构建
5.提交代码到团队主干
6.提交构建
速度与质量的权衡
速度与质量的权衡
10.自动化测试策略与方法
11.软件配置管理
12.低风险发布
13.监测与决策
14.大型互联网团队的FT化
15.小团队逆袭之旅
16.研发推动的DovOps
1.概述
精益思想
《精益创业》--最下化可行产品
双环模型
价值探索
提问：定义问题
锚定：定义结果目标指示器
共创:共同探索和创造 解决或验证该问题的多种有可行性的解决方案
精炼：选择最小的可行性解决方案
快速验证
构建：将最小可行性解决方案准确的转换成符号质量要求的软件包
运行：软件包部署到生产环境或交到客户手里
检测：对系统产生的数据进行监控
决策：数据信息与探索环得出的对应目标进行对比分析
4个核心原则
1.坚持少做
2.持续分解问题
3.坚持快速反馈
4.持续改进并衡量
2.价值探索环
【共创分析方法】1.量化式影响地图 2.用户旅行地图
【精炼工作原则】1.分解并快速试错 2.一次只验证一点 3.允许失败
【共创与精炼常用方案】1.装饰窗方法 2.最小可行特性法 3.特区法 4.定向探索法 5.稻草人法 6.最小可行产品法
【注意事项】：1.多角色参与探索 2.存在往复过程 3.风险不是等价的 4.上帝视角 5.唯数字论 6.蛇行效应
3.快速验证环
【工作原则】1.质量内建 2.消除等待 3.重复事物自动化 4.监测一切
4.组织文化
【安全、信任与持续改善】1.失败是安全的 2.相互信任 3.持续改善
【文化塑造】【行动原则】【度量原则】【持续改进】
5.软件系统架构
【持续交付架构要求】
为测试而设计
为部署而设计
为监控而设计
为扩展而设计
为失效而设计
【系统拆分原则】
作为系统的一部分
高内聚、低耦合
整个系统易于构建与测试
使团队成员之间的沟通协作更顺畅
常见架构
微核架构
微服务架构
巨石应用
架构改造实施模式
拆迁者模式：一次性重写所有代码
绞杀者模式：不改变或少改变原有遗留系统，通过增加新的服务来不断替代遗留系统功能
修缮者模式：通过迭代，对原有遗留系统进行逐步改造
6.业务需求协作管理
产品生命周期
概念阶段：清楚回答市场机会，客户需求的紧迫性、企业自身的竞争优势、产品的可行性以及自身产品团队能力等问题
孵化阶段：考察产品核心功能的完善度、满足典型目标用户的核心诉求程度
验证阶段：关注最小核心功能集的用户体验、早期用户的反馈、盈利模式、以及产研核心团队稳定性与加大资源投入的可行性
运营阶段：关注市场环境变化、客户泛化需求的存在性，以及投入产出比
业务退市阶段：不满足企业预期
每个周期分为准备期、交付期
准备期
1.目标阐述与理解
2.业务领域角色与流程识别，以及解决方案的探索
3.重大风险识别与验证
4.精炼并达成最小可行方案公示
5.评估与计划
交付期
分析、开发、测试
需求拆分
收益
1.建立共识、协调工作
2.小批量交付、加速价值流动
3.低成本拥抱变化
4.多次集成、及时反馈质量
5.鼓舞团队士气
需求来源
1.业务人员提出的业务功能需求
2.为了保障业务需求的实现与运行而必须满足的非业务功能需求
3.符合安全合规性而产生的安全开发需求
1.从原始需求列表中选出的带实现需求
2.需求细化过程中新发现的需求
3.已知且需要修复的线上生产系统缺陷
4.线上技术运营需求
5.前期预研需求
6.技术债需求
7.辅助测试需求
拆分方法
1.路径拆分法（功能路径）
2.按接触点拆分（页面显示或操作点）
3.按数据类型或格式拆分（垂直功能）
4.按规则拆分（先基础/后完善性）
5.按探索路径拆分
需求管理工具
1.用户故事地图
2.用户故事树
3.依赖关系图
4.数字化平台
团队管理方法/工具
1.团队共享日历
2.团队回顾
3.可视化故事墙
4.明确“完成”的定义
5.持续集成
6.故事验证
7.部署流水线原则与工具设计
初始流水线阶段
1.提交构建
2.次级构建
3.UAT部署
4.UAT结果
5.性能测试
6.内部体验
7.外包体验
8上传发布
设计原则
1.一次构建、多次使用
2.与业务逻辑松耦合
3.并行化原则
4.快速反馈优先
5.重要反馈优先
流水线平台的构成
1.工具链总体架构
1.唯一受信源
2.部署流水线平台
3.基础支持服务器
2.平台应当具备的基础能力
1.对事件的追溯能力：对部署流水线中发生的任何事件都应该能够追溯
2.对部署流水线产物的追溯能力：包括流水线任意产物、其对应的源，构建时的脚本和环境等
3.基础支撑服务的云化
1.协作过程解析
1.环境准备
2.提交构建
3.次级构建
4.部署生产环境
2.编译构建管理服务
1.任务管理服务：一个接收子服务，一个通知子服务
2.调度服务：负责从待构建任务列表中，根据一定的调度算法选择构建任务，并将发送到对应的构建机上执行
3.集群管理服务：负责对各类构建环境的管理
4.构建执行器：执行构建任务的代理，在集群中有很多个执行器，甚至一个计算节点可以有多个执行器
3.自动化测试管理服务：包括测试任务管理服务、测试用例调度服务、测试集群管理服务、用例健康挂你自动化服务
4.软件部署管理服务
5.基础环境管理服务：为上面三大管理（构建管理、测试管理、部署管理）提供环境准备，管理和监控服务
4.制品库管理
原则：制品库中，每一个制品都应该有唯一标识，并且连同其来源、组成部件以及用途等，一个保存为改制品的元信息。
分类
软件包库：临时软件包库A、正式软件包库B、外部软件包库X
镜像库：临时镜像库C、正式镜像库D、外部镜像库Y
8.利于集成的分支策略
分类
1.集中式版本控制系统（SVN）
2.分布式版本控制系统（GIT）
基本概念
代码仓库（codebase）、分支（branch）、主干（master）、
版本号（revision）、标签（tag）、头（head）、合入（merge）、冲突（conflict）
版本号（revision）、标签（tag）、头（head）、合入（merge）、冲突（conflict）
常见分支开发模式
1.主干开发、主干发布
2.主干开发、分支发布
3.分支开发、主干发布
分支模式
1.“三驾马车”分支模式
开发分支、预发布分支、发布分支
2.Gitflow分支模式
1.Master分支是正式版本的发布分支
2.Release分支是用于质量打磨的预发布分支。质量达标就可以合入Master分支和Develop分支
3.Develop分支是新功能进行集成的分支
4.Feature分支是为了开发某一功能特性。来自Develop分支，合入Develop分支
5.Hotfix分支是严重缺陷分支，来自Master分支，合入Master、Develop分支
3.GitHubFlow分支模式步骤
1)从Master上创建一个新的分支，以特性或缺陷的编号命名改分支
2)开发在新建的分支上提交代码
3)功能开发完成，并自测通过，创建Pull Request（简称PR）
4)其他开发人员对这个PR进行审查，确认质量合格后合入Master
2)开发在新建的分支上提交代码
3)功能开发完成，并自测通过，创建Pull Request（简称PR）
4)其他开发人员对这个PR进行审查，确认质量合格后合入Master
版本发布模式
1.项目制发布模式：预先确定某一版本所需包含的功能特性数量（没有明确时间）
2.发布火车模式：为每条产品线都制订好每个发布周期（有严格时间）
3.城际快线模式：固定三要素中的两个时间和质量维度，且时间周期相对较短。
本书提倡的策略：“主干开发”或高频的GitHubFlow分支模式
原则：
1.分支越少越好，最好只有一条主干
2.分支生产周期越短越好，最好在3天以内
3.在业务允许的前提下，发布周期越短越好
1.分支越少越好，最好只有一条主干
2.分支生产周期越短越好，最好在3天以内
3.在业务允许的前提下，发布周期越短越好
收藏
0 条评论
下一页
