DevOps之代码模块设计浅析

16天前

我秃了,也变强了!

DevOps之代码模块设计浅析

DevOps(开发:Development和运维:Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。----百度百科


—————————————————————————————————————

今天的主题就是有关DevOps的很重要的一部分,Development中代码模块的设计。

代码模块说复杂也不复杂说简单也不简单,复杂是说它上承接着任务模块,下关联着构建模块,功能涉及到代码的对比合并、质量分析、关联的任务项等,缺了它就凑不成完整的DevOps流程;简单是说该模块需要关注的点无非就是质量以及效率,一个项目在我看来代码才是根本,代码的产出质量效率越高,就越是节省项目的成本,有钱赚才是硬道理。

—————————————————————————————————————

代码模块的受众也无非两类人:开发人员和上层领导。

开发人员眼中的代码模块是branchtagcodemerge-requestquality等等诸多功能模块的混合体

(不行了,晕了)

但是到了领导的眼里,报表即可解决问题:

一类报表说了张三今天代码产出了多少的缺陷多少的漏洞

(垃圾代码冠军得主,就是你)

另一类报表说了李四本周就敲了10行代码效率极其低下

(是时候该炒李四鱿鱼了)

所以创造一个友好的代码管理功能交互页面以及简洁明了的代码质量效率报表界面成了代码模块设计的关键之处。

—————————————————————————————————————

接下来,我就拿自己正在参与的DevOps项目来做一下代码模块设计的讲解。

先说说供给开发人员使用的代码模块:

一个正常运转的项目,一定绕不开的就是源码的管理,但代码管理工具种类繁杂,诸如GithubGitlabSVN


也许A公司用着GitlabB公司用着SVN,自己的产品若只支持Gitlab代码库,那岂不是白白损失了B公司这个潜在客户?

(销售磨刀霍霍向产品)

所以,正确的思路就该是:我全都要!

要想实现全都要也很简单,无非就是配置文件加类加载器,通过判断接口传入的代码库类型来加载不同的第三方代码库服务集成类,这样就可以轻松实现你若有需要,我便可集成。

此处不再细述第三方的代码库集成方式,像GitlabBitbucket等代码库管理工具都有非常完善的rest api接口文档,开发人员可以参照文档挑选接口去定向开发需要集成的功能

Github Rest API官方文档:

https://docs.github.com/en/rest/reference

Gitlab Rest API官方文档:

https://docs.gitlab.com/ee/api/api_resources.html

Bitbucket Rest API官方文档:

https://developer.atlassian.com/server/bitbucket/reference/rest-api/

注:EnforcedServiceLoader为参照jdkServiceLoader,增强型的ServiceLoader

此方式同样适用于其他需要集成的服务,如任务模块(JiraZentao等)、文档模块(ConfluenceGitbook等)

目前,普元DevOps平台已支持的代码库有GitlabGithubSVNBitbucket,未来会有更多的适配代码库类型

下图是将第三方代码库关联至DevOps项目中去需要配置的表单界面

集成好了代码库服务,再说一下实际集成的功能,代码库文件的浏览、commit历史的浏览、分支标签的维护对比以及分支合并、代码质量分析等功能已足够开发人员使用,不清楚后续是否会考虑做云ide的集成,这又是另话了

(产品经理:伪) 


需要注意的是,通过配置代码库的webhook可以实现代码提交记录自动关联任务项,也可以实现代码提交自动触发构建任务(需要在指定的构建定义处配置好代码触发构建策略)


以上与webhook相关的功能就涉及到webhook回调接口的实现了,简单来说,就是写一个供给第三方代码服务器调用DevOps服务的接口,GitlabGithubBitbucket官方网站有详细的webhook回调请求的参数格式,通过判断回调请求的参数来实际调用自己服务的哪些功能就是简简单单“小case”的问题了

(小意思?!)

下图是Gitlabwebhook回调功能部分实现

—————————————————————————————————————

再来说说为给管理人员带来便利,DevOps的代码模块可以做到哪一步

(就是报表呗)

废话不多说,直接拍图:




以上三张图是基于代码报表数据生成算法以及系统参数配置的计算时间间隔来不间断计算生成的,看着每天不断拔高的数据以及开发人员不断比拼代码效率,领导露出了欣慰的笑容

上班第一件事,打开报表看一眼自己的代码效率无人能比(不存在的),又是幸福美满的一天呢!

数据统计时间间隔系统参数配置页面以及代码报表数据统计算法部分代码实现如下图所示:


最后一张报表展示的是当前项目关联的代码库的代码质量信息(简洁版),DevOps平台只是取了代码质量扫描报告的关键数据做了展示

要想看复杂版还是要实际的到报告原始界面查看,对了,普元DevOps采用的代码质量扫描工具是SonarQube(想了解工具请自行baidu),下图展示了DevOps自身代码的质量扫描记录


别在意今年为啥只有一次质量扫描,因为有专门的质量扫描的构建任务


(自己代码写怎么样都心里有点数,领导天天盯着呢)

—————————————————————————————————————

最后,做一下总结:

这一定一定不是DevOps的最终样式(鬼知道有没有最终样式),就代码模块而言,需要做的东西还有很多很多,需求是无限的。DevOps会在不断的更新过程中,不断地被完善,终会有一天也会长成参天大树。

(我秃了,也变强了)


关于作者:欣宇,普元Java开发工程师,擅长Java、MySQL、Jenkins等;参与DevOps的5.2-5.5版本的研发工作,参与九江银行的DevOps部署实施,参与碧桂园DevOps定制开发等。



关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!

COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。