DevOps是多年的实践的产物（众多人众多公司众多行业的实践分享），从而形成一门新的知识。它参与看敏捷框架FASe并结合管理经验积累形成了落地。这就是以故事为核心的：Epic史诗故事（面向客户的解决方案，常用用户场景方式，模拟客户实际使用系统的场景）+Feature用户故事（系统提供的功能）+story特性(每个故事都是小的，独立的给客户带来业务价值的行为)，对应了战略+计划+实行。

1.1.Epic

左边是最常见的按功能模块划分，个做个的需求，有很多弊端，后续返工很多，所以就引用了右边，基于用户场景，前后的引用故事场景，帮助研发更好的理解客户的需求，返工减少了。

也就是说，之前是没有理解客户需求，开发出来的没有满足客户需求，导致很多问题和前后端对功能、需求的理解各有各的看法和意见，所以返工是肯定的。

所以引用用户场景，需求：差旅费用、报销结算是用户场景；

1.2 Feature

可以理解系统提供的功能，描述方式：特性（是对功能/非功能的一个简短的描述）+收益（是对用户和业务价值的简短描述）--一个特性可能会有多个收益。

上面需求拆分成，费用报销、在写审批功能。

注意：一个特性最好是在一个版本中完成，如果是跨版本，需要再次的拆分。

1.3 Story

作为...可以干什么...以便...

也就是：谁在使用系统，如何使用系统，为哦什么使用系统

小结：Epic--可以拆分成---Feature---众向分解--story

以上都是功能级需求，其他非功能需求怎么办？Epic-->Feature--->story实际上可覆盖技术、架构、基础设施等这一类的需求，只不过不是从用户故事角度描述的。例如技术预言、性能、基础支撑能力等。

小结：此章讲了Epic+Feature+story概念，要记住。

第二节 DevOps敏捷过程--JIRA集成过程

1.JIRA的敏捷了解

这个JIRA是优秀的问题跟踪和管理工具，很多企业当做项目管理工具来使用。

提供了Scrum模板，创建项目的时候进行选择，内置了很多敏捷的核心要素和管理流程。

Scrum这个流程如下:

Epic史诗故事、Story是用户故事--》创建subTask是子任务--》Sprint迭代计划，子任务在这个完成--》根据其他需要创建其他的Task、bug等，归属到迭代计划中。

集成型的模型映射：左边是DevOps模型，右边是JIRA的模型。大部分通过名称意义映射

区别：

DevOps是在产品中定义Epic和Feature，在项目中对应Story，没有子任务概念。

JIRA是项目级管理，在项目中定义Epic，并且Story为核心进行迭代，可以创建子任务。

JIRA基础的难点

我们使用的方法：

信息通步策略，信息的源头在哪里，建议采用单向的，JIRA进行管理，在DevOps进行查看

查询统计效率：

工作项完成率根据多个状态进行统计，JIRA根据每个状态进行查询，效率很低，将JIRA数据同步到DevOps中后期再统计。

账户一致性：

提供多种认证方式，如下图，满足

小结：此章节了解JIRA和OevOps概念和使用建议。

第三节：代码质量-sonar集成

3.1 SonarQube的作用

我们平时代码的管理如下，代码质量的意义我想都知道。怎么去管理代码质量。

SonarQube是开源的软件代码管理平台

SonarQube 由上图4个组成。首先配置DataBase数据源、然后按照server，再然后按照插件、最后再按照scanner，具体安装方法百度。

第一IDE的安装

第二安装git相关

第三管理可以拉去代码分析

SQ配置：

Jenkins的安装：

DevOps构建：

小结：此章节讲了如何安装相关

第三节：DevOps代码质量与配置执行

SonarQube质量评估原理

如下图是java中统计结果，中间这部分代码违规是根据代码规则统计，其他的根据图中标识统计。

代码规则是通过插件方式的

按语言区分不同的插件，每种语言中分三类，bug（可靠性指标）、漏洞（安全性指标）、坏道（可维护性指标）规则，根据这些找到代码中的问题，另外右侧是代码的严重成功和问题解决的时间；

根据规则里面的规则统计的。

汇集集成了代码质量结果

了解了基本原理后。

质量配置：根据项目语言，项目中有多个语言可言根据多种语言配置。

根据需要激活这些规则可言对应问题的严重性

一个项目可言关联多个质量配置

质量阀的概念，有三个指标：正确、警告、错误

创建质量阀，选择关键的指标

在代码质量分析的时候，就会自动计算，最后给出综合评价

代码质量分析，两种方式

第一种：在构建配置中，增加这个任务，就可以对代码质量进行分析了。

在报告中看到代码分析汇总情况

点击链接，查看详细报告。

第二种单独执行代码分析

先关联代码库以后，就可以查看代码分析了。

在DevOps提供了报表：单元测试覆盖率报表、可维护性报表

通过与SonarQube中的可靠性、安全性、维护性等等方面对代码的了解。

第二章：DevOps代码库的管理

第一节：DevOps分支管理与实践

此章节无法详细文字描述，需要自己体会。

开发实际场景：

多个程序员开发版本，大家都提交到代码库，当某一天版本稳定，发布版本V1.0，后续人员在这个主干上继续开发，开发过程中，我们发现原来版本上发现bug，在主线上修复版本，这种方法不可取。因为后面多了新功能和新版本，这样不利于管理。

解决方法是在原来发布的版本上拉出一条分支，在这个基础上修改。

其他几种开发方式

2.1.1单主干模式

以前svn时候很常用，特点，所有开发人员都在主干上开发，所有成果都在主干上，开发阶段结束后，在发布节点简历发布分支，后续版本还是在主干上进行。

分支作用是修改bug等，分支修改后要合并到主干上。

缺点是都在一个主干上，一个出问题，都会引起其他出问题。需要持续集成、和持续集成测试来保证代码质量

2.1.2 Git-Hub模式

主干代码主要用于可维护一份可以发布的代码，任何新的代码和bug修复都需要在分支上完成。

所有开发人员在自己的分支上完成，开发完后提交申请，有代码评审，审核通过后合并到主干上。

非常开源方式多人协作，每个分支时间短、代码量少，使用方式简单。

有自动化、持续集成的保障。

2.2.3 dit-flow模式

比前面复杂点，有两类分支，第一类主干分支，用于存放可发布的版本，和github类似，第二类是开发分支，我们每个阶段提交的代码，不是看开发者在分支上进行。第三类是特性分支，不同的特性建立不同的特性分支，同时这些这些特性分支可以并行的开发，开发完成可经过测试可合并到开发分支上，多个特性完成后合并到开发分支，如果要发布版本，就引申出一条分支叫做发布分支，这是因为很多公司在开发结束到发布需要很多测试，需要bug的修改和功能特性的增加，到某天结束后就会合并到主干分支。还有一个分支叫紧急修改分支，在上面完成bug的修改，在上面修改同步到开发分支上。