关于Scrum+XP+DevOps的学习

最近听了ECUG大会上孙敬云老师的分享感受受益不浅，毕竟大学课本上只讲到瀑布模型就没有下文了，工做之后一直贯彻的都是Scrum路线，一直也没有时间好好的去学习整理这部分的知识，直到近几天听到了孙老师的分享，因此就在这里记录下孙老师的分享也总结我本身的思路。如下内容部分摘自于孙老师的分析PPT

1 软件工程之路

1.1 软件工程的演进

貌似大学的那门软件工程只给咱们讲到了1980年，以后的须要咱们走出校门，在社会中进行学习。

先来看下面这张图，是1980年至今的软件工程演化路线，像瀑布模型你们应该是耳熟能详。

进入1990年，Scrum这种，近几年应该也是略有耳闻，但是像极限编程这种可能就不多据说了吧。

再向后看，进入2000年，持续集成也就是CI/CD中的CI和敏捷开发近几年炒的火热，互联网公司争先恐后，kanban（今天公司产品说，我才知道kanban是日本人发明的）也有点大势已去，不过市场上应该还有很多公司在使用kanban。

走到了2010年，咱们所看到的应该就是几个随处可见的概念了，持续交付,DevOps,Scrumban（咱们近几年说的真正意义上的Scrum）

1.2 瀑布模型

在这里不详细叙述，只叙述几个痛点。

1. 产生客户价值周期长
2. 部门、角色之间存在壁垒
3. 没法及时响应需求变化
4. 价值流动不可见

1.3 敏捷开发

敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协做、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、可以很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程当中人的做用。

说人话，就是更注重沟通，快速产出新版本，而且更适应需求变动的的适合小团体开发的方法。

下图左方，是需求池的概念（好比jira中的backlog），好比7%的需求是现实中大量客户的需求，则咱们将这7%的需求做为优先级最高的需求。

下图右方，是迭代和反馈的概念。

敏捷开发中有敏捷宣言，能够更好地阐述敏捷开发的概念。

1. 个体和互动高于流程和工具（敏捷开发的站会落实了这一点）
2. 工做的软件高于详尽的文档（jira、miro等更好地代替厚重的需求文档）
3. 客户合做高于合同谈判（公司内各部门甩锅状况，难道不该该用合做为公司创造价值吗）
4. 响应变化高于遵循计划（快速响应时长需求，而不是错过市场变化）

1.3.1 Scrum实践

下图右上方是Scrum中的角色定义。

1. Product Owner（产品负责人，主要负责产品设计，需求筛选等）
2. Scrum Master（敏捷主管，主要负责项目迭代跟进等）
3. Scrum Team（敏捷团队，主要负责需求的研发测试部署等，包括Dev、Test、Ops等）

下图左方是用户故事（user story）,其实就是咱们传统意义上的需求，只不过以一种需求方的更委婉拟人的语气来说述该用户人群的需求。

例如：我是一个买家，我但愿个人购物车能经过价格排序，这样我就能根据我卡中的钱进行合理的消费。

下图中部，则是Scrum的核心流程。有不少公司光注重了其中的流程（好比站会），却没有获得其中的精髓。Scrum中把一个迭代叫作一个冲刺(Sprint)，这也是不少地方把计划会议叫作冲刺会的由来，通常一个Sprint为1~4周。核心流程包括4个会议，以下所示：

1. 计划会议（Product Owener、Scrum Master、Scrum Team）

   1. 从Backlog中按照优先级选择这个Sprint要作的User Story
   2. 向团队解释澄清User Story的需求，并决定是否将User Story拆解为更细粒度的Sub Task
   3. 团队估计User Story的Story Point（用以评估story的大小，有一种好玩的方式叫作Scrum Poker）
   4. 团队决定是否将User Story拆分Sub Task来进行跟踪
   5. 决定这个Sprint的目标和交付的User Story

2. 每日站会（Product Owener（可选）、Scrum Master、Scrum Team）

   1. 站会维持在15分钟之内，分迟早
   2. 团队成员讲述围绕3点：我作了什么，我将要作什么，我遇到什么困难
   3. 每人陆续进行讲述，为了快速响应，维持最新消息，包括需求调整等
   4. 以及进行高效沟通，传递信息，拒绝信息发散
   5. 肯定相关问题后，团体相关人员小范围讨论

3. 评审会议（Product Owener、Scrum Master、Scrum Team）

   1. 相似于传统意义上的验收阶段
   2. 介绍Sprint结果，按User Story顺序演示新功能
   3. 回答相关人员对展现的疑问，并记录其所指望的更改，收集反馈
   4. 若是遇到一些还没解决的障碍，则将障碍加入障碍Backlog
   5. 以User Story做为是否成功交付的标准来评价任务完成状况

4. 回顾会议（Scrum Master、Scrum Team）

   1. 回顾这个Sprint，收集Sprint的相关数据
   2. 产生看法，多问为何，找到各个方面的优缺点，进行复盘分析
   3. 进行头脑风暴分析解决方案，投票选出下期的改进项
   4. 探索提升效率和质量的方式

1.3.2 极限编程（XP）实战

极限编程是敏捷开发中最具成效的几种方法之一，如同其余敏捷方法，它和传统方法的本质不一样在于它更强调可适应性能性以及面临的困难。

它的基础和价值观是：

1. 交流（增强交流，解决信息不一样步致使的问题）
2. 朴素（秉持最小可用，勤于迭代，不作拍脑壳的无用功扩展）
3. 反馈（多接受反馈，以进行快速调整修改）
4. 勇气（在该重构时重构，当状态不对时，放弃思考，调整状态后从新思考）

它认为任何一个软件项目均可以从四个方面入手进行改善：增强交流；从简单作起；寻求反馈；敢于实事求是。

下图是极限编程的13个最佳实践。

1.3.3 思考本身的团队是否是敏捷

问问本身下面的几个问题：

1. 成员是否氢气的知道团队的目标？
2. 成员是否能够预测结果而且充满信心？
3. 成员是否主动作事而且为此负责？
4. 成员是否愿意持续改进团队？

若是你对上述几个问题的回答时确定的，那么恭喜你，大家的团队是关注发展的敏捷团队，若是你对上述问题有部分或所有否认，那么你可能须要调整你的团队，大家只不过是在关注敏捷的形式，而没有精髓。

1.4 DevOps模型

DevOps是一种开发、测试和运维之间文化沟通，经过自动化的方式来进行软件交付和架构变动的流程，使构建、测试、发布软件能更快捷、频繁、可靠。它的出现是由于软件逐渐的认识到，开发、测试和运维的紧密合做能够更好的交付软件产品和服务。

下图是DevOps的标准化流程，经过创建一个完备的团队来创建一条IT服务供应链，经过自动化实现高效率交付，不固定需求管理、工具链等，只专一于持续的稳定的价值交付

2 三部工做法

2.1 第一工做法（工做流）

这一步工做法是关于从开发到运再到客户的自左向右的工做流

2.1.1 定义工做流

下图展现了自循环工做流的流程，其中前4项属于Dev范畴，后4项属于Ops范畴：

1. plan（计划）
2. code（编码）
3. build（构建）
4. test（测试）
5. release（发布）
6. deploy（部署）
7. operate（操做）
8. monitor（监控）

2.1.2 工做流实践

下图左方是咱们针对上面的工做流的一种实践，是一种工做日志的方式，这种工做方式一样适用于敏捷开发（jira中的工做日志），其实DevOps的本质就是敏捷开发。

1. 过程名称
2. 输入
3. 输出
4. 工具
5. DoD（Definition of Done，完成的定义，能够理解为完成的标准）
6. 平均前置任务等待数（完成当前任务，依赖等待了多少任务）
7. 手工比例（手工操做的步骤占据了总量多少）
8. %C/A（返工指标，完成时间/总花费时间，总花费时间=完成时间+修复时间）
9. 处理时间PT(真正处理该任务所花费的时间)
10. 流动时间FT（从接收到需求到需求完成所花费的时间）

经过上方工做日志所记录的数据，咱们能够对咱们的工做进行阶段性的分析，好比：

1. 平均前置任务等待数能够用来判断咱们的任务分配是否合理
2. 手工比例能够用来提示咱们是否须要使用自动化来优化流程
3. %C/A能够用来判断一我的的工做质量是否须要优化
4. 等等

2.1.3 版本和分支策略

2.1.3.1 普通版本管理

1. 新需求拉一条新的分支进行开发，命名xxx feature branch
2. 新bug拉一条新的分支进行修复，命名xxx fix branch
3. master分支保持永远可构建成功状态
4. 每当新需求或新bug完成合并到主分支，触发主分支的pipeline构建流程

2.1.3.2 GitFLow实践

这种方案是基于GitFLow的标准来进行版本控制的。

该方案采用develop、feature、hotfix、release、prod等分支进行实践，比较适合版本并存的团队

1. develop：主开发分支，包含全部发布到下一个release的代码
2. feature：新功能开发分支，最后会合并回develop分支
3. hotfix：prod发现bug时，用来热修复分支，最后会合并回develop分支
4. release：发布版本时，基于develop建立的分支
5. prod: 用于发布到生产环境的代码的分支，只能合并不能修改。

这种方式很灵活，代码隔离也很好，只是过于繁琐。

2.1.3.3 tag版本实践

该方案是基于版本打tag的方式来进行版本控制的。

该方案采用master、feature、fix等分支进行实践，比较适合小版本滚动升级团队

1. master：主分支，该分支不容许修改，只容许合并，该分支永远保持可构建状态，发布时经过tag来进行版本发布
2. feature：新功能开发分支，最后会合并回master分支
3. fix：线上发生bug后，用于修复的分支最终会合并到master分支

这种方式很简单，可是对多环境的支持不是很好。

咱们推荐使用GitFlow+Tag的方式来进行版本控制。以触发多环境下的pipeline自动化流程。

2.1.4 规划流水线

这里主要是咱们的CI/CD的流水线的结构，可已使用Jenkins的pipeline也可使用Gitlab的pipeline。

这里连接下以前写的Jenkinsfile教程（Jenkins Pipeline 教程）

自动：

1. 代码检测（推荐使用SonarQube，教程）
2. 单元测试（很重要，java可以使用junit，其余的未调研）
3. 制品（过去的jar包，现在的docker image）
4. 集成测试（很重要，属于自动化测试中的一个重要环节）
5. 性能测试（大部分场景下可能不会每次都作）
6. 安全测试（跟性能测试差很少）
7. 部署预发布（这里泛指线上如下的全部环境）

手动：

1. 验收测试
2. 部署线上

2.1.5 Scrum+XP+DevOps流程

看过了上面的部分，你必定嗤之以鼻，由于下面的图其实就是上面的Scrum图+Pipeline的图。其实下面你的这张图才能真正意义上的指导咱们如何在工做中实践Scrum+DevOps。我将下面的图分层了4块，让咱们一块儿看看下面的图吧

Scrum+XP流程

第一部分的需求池的这个概念咱们在上方的Scrum中已经看到了，在这里不作详细解释，若是记不太清了，能够回到上方#1.3.1 进行复习。

第二部分的Scrum流程须要咱们再来回顾一下，一个迭代中的4个会议还记得吗，不记得就回去看看吧，经过小迭代来进行可持续的速度小型发布，其中要落实XP的13个实践，包括集体全部权、简单设计、重构等等。

CI/CD

经过代码版本控制来触发咱们的的CI和CD的构建。

经过发布编码标准，测试驱动开发，代码riew等来提高咱们的代码质量以进行优质的代码持续集成。

在持续集成以后，迎面而来的是构建、测试、部署，这几个步骤的才是真真正的表现咱们的团队的持续交付的质量。

在3和4两个步骤，咱们会看到下方有包含对号和错号的表格，这个咱们会在接下来的地方讲到，这个是个CI/CD反馈表，用来表示咱们某个阶段的CI/CD的缩略状况，能够经过这个反馈来进行相关的分析。

2.2 第二工做法（反馈流）

2.2.1 持续反馈

下方的图是CI/CD的持续反馈图，可能作过Jenkins的Pipeline的小伙伴已经能看出它了。

顶部的“表头”其实就是咱们的Pipeline的流程，而每一行是咱们的历史构建记录，经过这张图咱们能够清洗的看到咱们在某一阶段的pipeline的执行状况，就能够看到咱们在哪个节点发生错误的状况比较高。

在这个流程中最重要的就是测试部分，若是咱们的团队对包括单元测试在内的测试环节若是不是很重视，那这个反馈将对咱们的团队毫无心义。

在DevOps中，咱们推崇测试驱动开发，经过先写单元测试，集成测试等用例来驱动咱们的开发进行编码。

2.2.2 查看在制品

这里的制品的含义就是咱们所构建的，好比java的jar，golang的native，docker的docker image等。

经过DevOps的反馈，咱们能够查看制品所在的story的目前阶段

2.3 第三工做法（学习）

2.3.1 不断尝试和重复学习

让咱们再来看下面这张图，对比上面的那种图，在咱们的编码、测试、部署三个阶段多了个小锤子的标志。

这里的编码、测试、部署，分别表明着开发、测试、运维，三个岗位须要不断的尝试、配合和重复学习来让这条IT服务供应链更快速更稳定更自动化，让信息反馈更精准、更全面的覆盖到整个服务生命周期。

2.3.2 测试四象限

首先画一个由x轴支持评价和y轴业务技术导向组成的四象限，咱们将咱们DevOps中的全部种类的测试流程放入其中，来将每个测试落实在一个二维区间内，再在每一种测试上标识一个工做投入程度，组成下面的图。

咱们以前提过，在XP极限开发中，咱们推崇测试驱动开发，由于测试驱动开发可让咱们在开发以前更加深刻的理解业务，而且基于接口定义程序，更好的组织咱们的软件架构。

因此下图是咱们的测试流程应在咱们的工做中所占有的工做比例，若是全部的工做经历为100%的话，那么6颗星则为60%，每颗星占据10%。

良好的开发习惯，和标准的测试流程可让咱们的代码质量更上一层楼。

2.3.3 运维四象限

上面咱们说了测试的四象限，这里咱们说说运维的四象限，咱们以紧急性为x轴，重要性为y轴，这个四象限实际上是不少工种的人都会使用到的，会将咱们天天的任务放到里面，用来肯定任务的优先级，咱们知道基于这种四象限，咱们的优先级会有下方四种：

1. 紧急且重要
2. 紧急不重要
3. 重要不紧急
4. 不重要不紧急

咱们将运维的工做放在上面，若是大部分的工做都落实在紧急且重要的第一象限上的话，那么说明咱们的DevOps流程是有问题的，好比咱们的运维的大部分精力都在天天的线上紧急修复之类的任务，就说明咱们的开发和测试的质量是有问题的。

运维的工做不该该重点在右方，而应该重心左移，偏向于重要不紧急，多作一些规划性的工做，好比从传统部署方式转向k8s容器编排等工做。

3 工程化指南

3.1 实践整合

在上面咱们将上面说讲述的知识合并起来，组成咱们真正在工做中实践所要用到的东西。Scrum+XP+DevOps

3.2 创建工程师文化模型

小团队内部要作到：

1. 可视化面板和主动领取任务(信息扁平化，加速效率，共同目标帮助队友完成任务)
2. 成为用户故事的负责人（每一个人都要有主人翁意识，认为本身是UserStory的主人）
3. 20%的非功能性需求（给开发一点非业务的技术需求，提高多巴胺，产生乐趣）
4. 合入主干的代码须要审核（合代码须要组内review，下降代码出问题的几率）
5. 周期性的技术分享（每一个人都要分享，对本身所学到的东西进行沉淀，同时也吸收组内其余人的分享）

公司级别：

1. 举办黑客马拉松（选择一个主题，让公司的开发进行参与，进行开发，讨论，提高技术激情）
2. 举办技术沙龙

3.3 目录结构

定义每种语言的标准的目录结构，好比下方的目录结构就是Node.js的标准目录结构，我将一些语言级通用的结构用红框画了出来。

1. src
2. test
3. .env
4. Compilefile
5. Dockerfile
6. Jenkisnfile

3.4 版本控制规划

下图使用的是基于Tag的版本控制，我这里看推荐使用GitFLow+Tag的方式来进行基于Tag多多环境的版本控制的方式进行构建使用。

3.5 快速失败的流水线

下图中的快速失败的概念是指当pipeline中某一节点未达到经过的要求，则再也不运行以后得节点，以当前节点的失败为整个pipeline的失败。

像jenkins原生就兼容快速失败。下图是jenkins最新的Blue Ocean界面，很友好的。

3.6 可视化反馈平台

在第二工做法中，咱们学习到了反馈工做流，若是使用jenkins构建pipeline的时候，咱们就能够经过jenkins原生支持的可视化结果来了解到咱们近期的CI/CD状况。

3.7 持续改进

在咱们的产品设计中，有一个MVP的概念，它的意思是最小可行产品，这个概念来自于《精益创业：新创企业的成长思惟》这本书中，书中提倡首先定义一个面向市场的最小可用的极简原型产品，而后再不断的试验和学习中，以最小的成本和最有效的方式来验证产品是否符合用户需求，灵活调整方向，以达到“快速失败，廉价失败”的方式来验证产品是否符合市场需求。这是一种不断学习，挖掘用户需求，迭代优化产品的方式。

咱们对待咱们的团队，其实也要像对待咱们的产品同样，不停地学习，不停地尝试，不停地优化，这样让咱们的团队快速成长，要容许咱们的团队犯错（可是不能重复掉进相同或类似的坑中）。

3.8 更多的质量保证

3.8.1 CI/CCD

经过良好的测试+自动化流水线来提升咱们的代码的质量

在部署前：

1. 集成测试
2. 性能测试
3. 安全性测试

部署后测试：

1. 自动化测试
2. 验收测试

3.8.2 环境与配置管理

经过配置中心来区别应用在各个环境中的配置，以防止出现踩到带着开发测试的配置上线的这种老旧坑。

3.8.3 制品库管理

制品库推荐也一样隔离开，预发和生产使用同一个制品库，开发和测试使用同一个制品库，在两个制品库之间，须要人为来审核和同步。

3.8.4 流程控制

这里的流程控制主要指的是CI/CD的流程控制。由于咱们都知道jenkins单节点在同一时间自由一个pipeline能构建，也就是说单节点jenkins不能多条pipeline并发构建。因此咱们须要搭建分布式的jenkins集群，来对pipeline的构建进行调度。

另外一种更好的方式就是经过gitlab或其余支持并发pipeline构建的工具进行构建。

下方的pipeline中在测试环节分红了三个分支，这个特性咱们再使用jenkins的pipeline时是有完美支持的，名字叫并行流，是根据条件来判断三个分支是否进行的。

3.8.5 数据收集和监控

咱们的服务上线后，咱们须要使用两种方式来确保咱们线上使用的服务可以健康的提供服务。

1. 日志
2. 监控

经过采集咱们的线上的服务的日志，来对线上日志进行分析，达到实时监控服务健康状况的需求。这里推荐使用市场较为开放通用的开源方案ELK

咱们同时还要对咱们的中间件，流量，物理硬件等进行相关监控，以肯定基础环境的实时监控状况，这里我推荐使用Prometheus+Granfa进行监控。

3.8.6 容灾

当咱们的应用日益复杂且用户量逐渐提升后，咱们须要对咱们的服务进行容灾配置以及周期醒的混沌工程演练。咱们的服务应该像下图同样逐渐进阶为可用性更高的部署方式。

3.8.7 紧急事件处理

咱们永远都不能心安理得的拍着胸口说咱们的服务很是的问题，可用性能达到100%。由于100%是咱们的服务的可用性极限，就算咱们的服务可用性作到6个9，8个9，可是永远也达不到100%，永远只能无限的趋近于100%。由于咱们永远都没办法避免黑天鹅事件。可是咱们能作的是出现黑天鹅事件后，咱们要快速响应，将咱们的损失降到最低。下面就说说当出现线上故障的时候，咱们应该怎么作才能更好的减小咱们的损失。

事故发生前（凡事有预案）:

1. 提早准备可能出现的事故
2. 全员参与容灾演练
3. 多作混沌工程，提升服务的可用性和健壮性

事故发生时（先通报，后处理）：

1. Ops和Dev相互通报
2. Ops和Dev各自向上级汇报
3. 主管决定是否继续向上级汇报

事故处理中(先止损，后查因)：

1. 是否有处理预案
2. 有预案，Ops主管10分钟内作回滚决定
3. 无预案，Ops主管和Dev主管决定回滚和补救方案

事故处理后（反思，定级）：

1. Ops通报事故处理结果
2. 24小时内主要责任部门牵头矩形Case Study
3. 对事故进行定级

本文来自 纳兰小筑，本文不予回复，评论请追溯原文
查看原文