DevOps入门笔记

视频教学:https://study.163.com/course/courseLearn.htm?courseId=1004170021#/learn/video?lessonId=1048129542&courseId=1004170021目录第一章 DevOps基本管理第一节:DevOps需求定义-故事设计1.1.Epic1.2Feature1.3 Story第二节 DevOps敏捷过程--JIRA集成过程第三节:代码质量-sonar集成第三节:DevOp.
摘要由CSDN通过智能技术生成

视频教学:https://study.163.com/course/courseLearn.htm?courseId=1004170021#/learn/video?lessonId=1048129542&courseId=1004170021

DevOps到底是干什么的?为什么我们要学习这门课程,它跟软件开发有关,跟测试有啥关系?

其实这门课虽然大部分跟软件开发管理或项目管理有关,但是我们测试跟开发相辅相成,谁都离不开谁,所以测试要随开发走,比如持续集成你得有持续集成测试吧,怎么部署,在哪个节点部署测试,怎么实施自动化,你都需要研发那边怎么部署的,持续集成开发等。所以必须掌握和理解这个DevOps。

目录

第一章 DevOps基本管理

第一节:DevOps需求定义-故事设计

1.1.Epic

1.2 Feature

1.3 Story

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

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

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

第二章:DevOps代码库的管理

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

2.1.1单主干模式

2.1.2 Git-Hub模式

2.2.3 dit-flow模式

第二节:DevOps代码库集成

第三章 DevOps的部署管理

第一节 DevOps部署设计

第二节:DevOps部署转换

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

第四节:DevOps蓝绿部署

第四章 DevOps构建管理

第一节 DevOps构建之jenkins

第二节 DevOps构建定义与编排

第三节 DevOps构建策略与管理

第四节 DevOps构建执行与跟踪

第五章 DevOps组件管理

第一节 DevOps环境分类

第二节 DevOps云资源管理

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

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

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

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

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

第七章 DevOps有效管理干系人

第一节 DevOps失败和管理项目干系人

第二节 DevOps理解项目干系人的期望

第三节 DevOps如何让干系人满意


第一章 DevOps基本管理

我们知道在迭代开发中,我们需要需求的稳定,也就是说一个执行迭代的过程中,尽可能的保持稳定,做什么不做什么是要很明确的。而实际上事宜愿为,每次迭代需求肯定都会发生变化。这就是客户需求。

如何准确描述客户需求转换为开发需求,这是非常重要的。

第一节: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(可靠性指标)、漏洞(安全性指标)、坏道(可维护性指标)规则,根据这些找到代码中的问题,另外右侧是代码的严重成功和问题解决的时间;

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

汇集集成了代码质量结果

了解了基本原理后。

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

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

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

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 3
    评论
刚刚发布的ThoughtWorks技术雷达 建议技术团队“暂缓或谨慎”使用反模式“CI theatre(伪CI,可以理解为不完整的持续集成)”。 “伪CI”描述的是实践持续集成(CI)过程中的一些错觉,然而这些并不是真正的CI实践。 基于持续集成,我和同事 Emily Luke做了一些研究, 我将分享伪CI是什么样的,为什么我们建议你“暂缓或谨慎使用”,以及预防伪CI的方法。持续集成我最喜欢的CI定义来自于continuousdelivery.comCI开发人员定期(至少每天)将他们所有的工作集成到主干(也称为主线或主干分支)这个引用中暗含了CI实践的两个基本原则。第一个是“把他们所有的工作集成到主干”;第二个是“至少每天”。对于CI还有一系列其他原则和实践,例如:将所有内容都检入您的代码库,构建每个提交,自动化构建,保持快速构建,并有可以自我验证的代码, 还有Martin Fowler 关于持续集成的评论中的可视化故障并立即修复故障等。我个人认为 每天至少检入代码到主干分支一次 是CI的基础。没有达到这一点就只是伪CI而不是真正意义上的CI。伪CI是什么样的?这是我们调研到的一个故事,一位经验丰富的开发人员(让我们称他为David)来自湾区的一个中型创业公司,每周有两次产品交付。 David说他的组织正在践行CI,他说:“是的,我们用Circle CI”,他描述了一个具有挑战性的场景,曾经在一个分支上工作了一段时间,大约修改了100个文件和7000行代码,然后在代码审查阶段就开始招架不住了,因为他要向他的同事解释所有的代码变更的原因。“最具挑战性的事情是你最终要将一大堆功能集中到一个提交里,因为它们都是这个组件的一部分”,他解释说:“我希望有一个更好的方式来分解这些提交,因为很难把所有事情(变更历史)记在脑子里。”如果这个情况你听起来很熟悉,那么你也在做伪CI。 如果有下面的这些场景,那么你们就是在做伪CI:当有人问起你们在实践CI吗? 如果你说我们有一个CI服务器并且我们使用X工具在我们的调查中,只有10%的参与者承认有CI服务器与CI践行不一样。 相反,90%的个人表示他们正在践行CI,无论他们是否有专门从事CI的基础知识。 所以简单的认为只要有一个CI服务器就是“在做CI”,这就清楚地表明是在做“伪CI”。使用长期开发分支,但不会定期检入master主干在David的故事中,他们并没有实践每天检入master主干,这就是“伪CI”的标志。 这是我们在调研中常看到的一种模式,其中团队在master主干上运行CI,但不频繁构建,也不是每天都在提交。 或者他们在分支上运行CI,但不会频繁的集成到master主干。 只对特性分支运行CI,其实应该称之为持续隔离(continuous isolation)才对.合并分支时感到焦虑和疲惫真正的持续集成要把代码所有者的责任意识扩展到整个团队。 这改变了团队内部人员的观点以及他们对失败构建的态度。 不再是“我的宝贵的分支”,或是“我的错误导致构建被破坏”,而是“我们的代码”和“我们的失败”。David遇到焦虑和疲惫的事实清楚地表明,他忽略了CI的一个重要的优势:持续反馈和代码集体所有权。伪CI还有更多的一些现象,虽然我们发现有一些并不那么常见,但它们仍然存在一些问题,构建的时候,仅有极少的测试覆盖允许构建长时间处于失败状态虽然David的团队引入了一个备受尊崇的CI工具和常见的流程,如特征分支和代码审查,但他们并没有实施全套CI实践,因此错过了许多好处。 我们遗憾的发现,在我们的研究的组织中90%发生了这种情况。一些组织实施伪CI中反而错失了CI的主要优势 - 快速反馈,代码集体所有权,并准备达成持续交付如何避免,预防和解决伪CI的问题?如果您确定可能正在遭受伪CI之苦,则可以通过三种方式来解决问题并进行持续改变。1. 提交更频繁回到根本,尽量频繁地提交,每天至少提交一次应该是最低目标。 如果你还没有开始做CI,这就是你可以开始的地方,即使你在做CI,依然会有改进的空间。我喜欢“频率降低难度”的说法。 往往我们在做一些事情时,任务变得越小,则其更容易被实现。 持续集成就是是一个典型例子。 我的建议是要更加频繁地检入你的代码到代码库并且将开发分支集成到主干分支,至少每天集成一次”。2. 基于主干分支开发有很多论坛在讨论基于主干还是基于开发分支进行开发,我不想讨论那些血淋淋的细节。 然而,在我们的调研中,当我们与一些曾经在实践CI过程中感到痛苦的人交谈时,没有引入主干开发的团队对此有更深刻的感受。 DevOps现状调查报告-2016 还发现,基于主干开发和持续集成是达成持续交付的关键因素,同时也能建设更高效能的团队。基于主干的开发肯定会有一定的挑战,但它可以把问题提前暴露出来,而不是要等到代码合并、代码审查甚至到延迟发布的时候。如果你想达到更好效果的CI和CD,我建议在主干上做开发,或者如果你更愿意使用短周期的临时分支(合并到主干之前不到一天)进行开发,那么最好同时不要超过三个以上的活跃分支。3. 自动化自动化是做好持续集成的基石,所以如果你还没有自动化一切,现在是开始的好时机。 如果你认为已经实现了所有自动化的功能,那么每次有人手动地做任何事情超过一次,便要问自己“这个为什么不能自动化”? 我已经观察到自动化不仅可以帮助您在CI中变得更好,还可以帮助您开始持续交付。总结现在你知道什么是伪CI了,如果你的团队正在这么实践伪CI,那么你可以阻止这种情况继续发生了。 如果您仍然感到困惑,我建议你在Martin Fowler的博客“CI Certification test”做一个测试, 以确认你的组织是否正在做可靠的CI。 如果你通过了CI测试,那太好了,现在是考虑您是否准备好实施持续交付的时候了。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

测试狂人

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值