关于运维:你的DevOps中有完善的持续交付体系么

37次阅读

共计 2878 个字符,预计需要花费 8 分钟才能阅读完成。

背景:

DevOps 曾经成为软件开发畛域一个煊赫一时的名词。麻利开发、继续交付、CI/CD,K8s…这些支流的开发理念、工具无一例外都与 DevOps 有着很强的分割。这种环境影响下,传统的运维团队均开始向 DevOps 进行转型。一时之间运维开发、SRE、工程效力工程师需求量大增,无论公司大小,都会开始着手 DevOps 的从 0 到 1 的建设。咱们开始搭建工具链、部署流水线、集成自动化测试工具、开发自动化公布零碎……所有的一切都是为了欠缺咱们自动化体系,从而进步开发效率,优化产品质量。

那么问题来了,你团队所建设的 DevOps 体系,曾经是欠缺的 DevOps 了么?

注释:

咱们如何去评估目前 DevOps 中继续交付的建设状况呢,这里笔者总结了一些咱们在 DevOps 初期应该进行的一些工作,这些工作大多数属于工具链的集成,咱们能够对照下述十四条关卡,来验证一下咱们的 DevOps 建设中继续交付这一环节是否走在了一条正确的路线上吧。

1,版本控制

版本控制是指通过记录软件开发过程中的源代码、配置信息、环境、数据等,疾速的复原及拜访任意一个版本。版本控制最次要的性能就是追踪文件的变更。

罕用版本管理工具:git

2,最优分支策略

分支的品种很多,大多数团队会应用到骨干分支、开发分支、长期分支、性能分支、预公布分支、bug 修复分支等等。那么如何抉择一个最优分支策略,是咱们开发团队必须去标准的一件事。分支策略与版本公布频率之间有肯定的相关性,咱们要依据本人团队开发模式以及我的项目迭代周期来抉择最优的分支策略。

3,代码动态扫描

代码动态扫描须要从上面几个维度进行查看:复杂度散布、反复代码、单元测试统计、代码规定查看、正文率、潜在 BUG、构造与设计。通过在构建 pipeline 中加设代码动态扫描的品质关卡,确保咱们的代码能够达到一个可公布的级别。

罕用的代码动态扫描工具:如 SonarQube。

4,80% 以上单元测试覆盖率

进步单元测试的意义最重要的一点是保障代码所对应的性能失常、而单元测试覆盖率的查看是以一种束缚形式来标准开发人员应用单元测试,通过设置单元测试覆盖率的关卡来保障开发代码的正确性,并让单元测试逐步地变成开发习惯。

5,破绽扫描

每个我的项目中,高达 99.9% 的代码来自于内部依赖,为了防止反复造轮子,咱们援用了大量的内部开源框架及组件,这些内部依赖是否有平安,是否存在高危破绽,开发人员个别是无奈关注到的,所以咱们须要一款产品能够集成到咱们开发的 IDE、设置成为构建流程 pipeline 中的品质关卡、无缝的对接到咱们的制品库中,来扫描咱们所有的内部依赖。

罕用破绽扫描工具:JFrog Xray

6,制品治理

制品是构建过程的产出物。包含软件包、测试报告、利用配置文件等。制品治理是对软件研发过程中生成的产物的治理,个别作为最终交付物实现公布和交付。你所治理的制品能够统称为二进制文件,制品仓库则能够提供所有二进制文件的治理能力,提供全语言的依赖解析能力以及收集整个软件生命周期的信息与制品关联。

罕用制品治理仓库:Artifactory

7,开源协定扫描

开源协定有上百种,宽松水平不一。是否容许商用、是否能够批改、批改后是否须要持续开源等都是每种协定特有的个性。咱们作为用户,作为开发者,为了进步开发效率,防止反复造轮子,难免会援用大量的内部组件及框架,那咱们在 DevOps 建设过程中则必须留神对开源协定的治理及扫描。

罕用的开源协定:

l Apache 2:间接应用须保留原始许可申明,若对其进行批改,需向用户阐明。

l MIT:必须保留原始许可证申明

l BSD:必须保留原始许可证申明,局部版本不得应用原作者姓名用于软件销售

l GPL:若包涵 GPL 代码,整个我的项目则必须应用 GPL 许可证。

罕用的协定扫描工具:JFrog Xray。

8,不可变基础设施

不可变基础设施是指任何基础设施实例在部署后永远不会被批改。如果须要以任何形式更新,修复或批改某些内容,则会应用一批新的实例去替换,并在通过验证后,将新的基础设施实例上线,替换掉旧的实例。这种在当年在物理机或虚拟机上无奈疾速实现的这种不可变基础设施的理念,随着 docker 的遍及正在飞快的倒退,咱们能够通过容器的形式疾速的实现。这种模式能够为咱们缩小配置管理的累赘,并使得 DevOps 更加容易实际

最佳实际形式:Docker

9,集成测试

集成测试是在单元测试的根底上,把软件单元依照软件概要设计规格阐明的规格要求,组装成模块、子系统或零碎的过程中各局部工作是否达到或实现相应技术指标及要求。

10,性能测试

性能测试方法是通过模仿生产运行的业务压力量和应用场景组合,来测试零碎的性能是否满足软件的性能要求。艰深地说,这种办法就是要在特定的运行条件下验证软件系统的解决能力。

11,变更治理

在 google 的 SRE 体系中,变更治理是 DevOps 体系中最为重要的一个局部。依据以往的教训,90% 的线上故障是因为线上变更导致的,该变更起因包含软件、硬件、环境等所有因素。建设变更管理体系目标就是为了疾速定位线上问题,止损因为变更造成的线上故障,及时告诉相干人员做好故障预防工作。所以,变更管理体系也是须要咱们重点去建设以及欠缺的。

落地形式包含但不限于下述几点:

l 运维人员、对应的开发及测试人员、产品经理等微信告诉

l 大屏滚动播放最近的变更记录

l 变更记录同步到监控零碎

12,性能开关

性能开关概念很容易了解,通过性能开关咱们能够在运行过程中对某一性能进行启动和敞开,在麻利开发模式下,为了疾速迭代,在某些团队没有齐全筹备好的状况下,咱们能够通过性能开关的形式将新性能上线并通过配置屏蔽该性能,直至所有团队准备就绪,整个性能波及到的服务全副上线后,能够关上此性能开关,提供用户应用。

通过性能开关的计划,咱们能够疾速迭代,不用进行简单的集成测试及大版本交付,实现真正的麻利开发、小步快跑。

13,较高的接口测试覆盖率

进步接口测试覆盖率就意味着咱们能够进步自动化测试的覆盖率,在每次构建流水线中能够主动部署咱们的我的项目,通过接口测试来实现根底的自动化测试。另外接口测试能够提供给运维平台一个监控服务是否稳固的根据,咱们能够通过监控平台实时触发接口测试,来判断线上的服务是否仍然稳固运行。通过这种接口测试,咱们能够最快的速度定位到某些线上某些性能的故障。

14,零停机公布

无论应用蓝绿部署、还是金丝雀公布,咱们的指标只有一个,就是零停机公布。零停机公布是指在对用户不进行服务的前提下进行版本的迭代,修复 bug、援用新性能等操作。是否领有一个健全的零停机公布体系也将是咱们 DevOps 建设中非常重要的一个步骤。

总结:

DevOps 并不是咱们建设起来工具链就能够实际的一个理念,文中所介绍的十四个关卡也仅仅是 DevOps 体系中小小的一部分。开发团队组织架构的合理性、平安风险管理能力、技术经营、需要治理、架构设计、工程师文化等都是咱们 DevOps 建设过程中须要探讨的课题。


** 欢送观看 JFrog 杰蛙每周二在线课堂,点击报名:

https://www.bagevent.com/even…

**

正文完
 0