DevOps入门心得笔记--未完

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的修改，在上面修改同步到开发分支上。

第二节：DevOps代码库集成

代码库的作用，好处，做开发的同学都知道。

常用的代码库：SVN、git最多

第三章 DevOps的部署管理

第一节 DevOps部署设计

第二节：DevOps部署转换

从部署环境到实际开发环境的全过程

第三节：DevOps部署转换至ansible集成

第四节：DevOps蓝绿部署

是对版本的修改和升级，让用户无感知，版本的上线或下线

我们把正在服务的环境称为绿环境，要发布时，我们准备一套和生产环境一样的蓝环境，先把最新版本发布到蓝环境中，在蓝环境中进行冒烟测试，当一切准备完后，

从路由配置中指向蓝环境，这样用户是无感知的。

数据迁移

第四章 DevOps构建管理

这章节DevOps的基本操作

第一节 DevOps构建之jenkins

便于方式很多

为什么要jenkins，强大的集成能力

git ‘https：//github......’这个是拉取代码

第二节 DevOps构建定义与编排

构建定义：

任务编排

移动端

第三节 DevOps构建策略与管理

为什么要设置这个，因为我们要频繁构建，所以要高效。

devops一般设置10分钟

为了节省存储空间

第四节 DevOps构建执行与跟踪

点击click链接就弹出这个任务的执行日志

任务执行失败了，我们也可以提供日志定位

点击具体想可以看到

第五章 DevOps组件管理

第一节 DevOps环境分类

第二节 DevOps云资源管理

第三节 DevOps之不容小瞧的仓库介质

第六章 DevOps如何开好项目启动会

此章节跟项目管理PMP类似

第一节 DevOps为什么要开项目启动会

第二节 DevOps何时开项目启动会

第三节 DevOps怎么开项目启动会最高效

第七章 DevOps有效管理干系人