Web DevOps / plan / code / build / test / release / deploy /operator / monitor

s

https://www.zhihu.com/question/58702398

https://baijiahao.baidu.com/s?id=1722038702403831580

百度词条是这么解释的: “ DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运维工作必须紧密合作。”

优势:基于持续部署于持续交付,是部门之间协作的一组流程和方法,提升效率,提高员工参与感。

 《全球 DevSecOps 现状报告》在 4300 份样本中,开发人员占比 41.67%,SRE/DevOps 占比为 10.25%

 《中国 DevOps 报告》在 1862 份样本中,开发人员占比 35.18%,SRE/DevOps 占比为 6.87%

个人理解来说,Devops就是一种便捷,适合于公司的一套体系,这套体系包括开发到测试再到运维的一个流程,总之有了这个体系就能更加快速的实现客户的需求。这东西就是为了更好的服务客户!

 

 

 

 

上图意思就是代码需求设计到开发到提交构建到测试再到部署到运维到监控的流程。

 

 

 

 

上图来自网络比较形象表示应用实现的演变过程。

 发展到现在的DevOps,之前有哪些流程在被使用,第一种就是传统的单架构,集中部署式,这个怎么理解,就是一台机器,一个应用。想做个应用,找个服务器,上传打包好的demo-jar包,开启服务,监控就是看一下日志,没问题就OK。基本就是:设计-开发-测试-部署

第二种就是多个机器多个应用所谓的敏捷开发。这时候一个人就不够了,公司大了,机器多了,开发一个人管不过来了,就得找点专门管理机器,管部署的运维人员了。开发也多了,水平也是参差不一,全都要是能直接连机器,这上面领导估计都睡不好觉。然后运维就搞点脚本,减少重复的操作,然后还不太愿意开发变动太多。开发本能又不得不变动,导致开发运维还是有点矛盾的,开发想部署还得统一听指挥,这里开发运维其实还不是那么紧密。 

打个数学图形比喻,本来需求分析要个六边形,到设计变成长方形,到研发变现菱形,实际交付变成三角形。

 

 

 

 

再到第三种微服务架构的devops。到这里,公司体量变大了,框架也有了,应用很多东西就比较复杂了,再想改动就比较麻烦了,再推倒重来那不大可能了,只能小模块,小功能一点点实现了。所以得拆解,拆成一个个小小的服务来单独部署,各个直接也可以互相调用,这样的话,就不用每次改动个东西还得找运维求着他同意才能发布,运维还烦你呢。干脆找一些机器,专门放这些小服务的代码,再利用前面说的Gitlab之类的进行cicd流水线式操作,我改动一点,自己去发布部署。再搞一个日志监控的模块,开发自己看日志,这样开发也可以分担运维的一点工作,自己开发的东西日志还是自己最清楚,这样还能快速定位到应用的问题。这样确实是要好多了,能够快速部署快速实现某些功能。

我们知道,一个软件从零开始到最终交付,大概包括以下几个阶段:产品规划、开发编码、构建、QA测试、发布、部署和维护。

 

最初大家说到DEVOPS,都是指的‘开发运维一体化’,如下图:

 

 

 看了上面这个图,就知道了,devops就是不断开发测试部署重复这过程,就实现了快速开发快速部署快速实现,反正就是快速实现客户的需求,客户是上帝,这样快速开发,客户也能快速看到结果,省得像以前开发半天,开发出来客户说我去你这是啥,我是要这么个东西?

 现在好了,客户想看就看,不满意快速改动实现,客户想要啥就给开发啥,到时候客户满意了咱也能赚钱不是。

 再说说构建devops平台需要哪些工具,工具组件啥的其实很多,但关键在于适合自己的公司和团队才是最关键的。我下面列举一下。

 项目管理(PM):jira。运营可以上去提问题,可以看到各个问题的完整的工作流,待解决未解决等;

 代码管理:gitlab。jenkins或者K8S都可以集成gitlab,进行代码管理,上线,回滚等;

 持续集成CI(Continuous Integration):gitlab ci。开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

 持续交付CD(Continuous Delivery):gitlab cd。完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。

项目管理:jira

代码管理:gitlab

镜像仓库:VMware Harbor, 私服nexus。

容器:Dockercontainerd

编排:K8S

 镜像扫描:Clairctl

 配置:Nacos

 服务注册与发现:etcd

 服务治理:Consul

 脚本语言:Python

 日志管理:ELK、Cat + Sentry

 显示面板:Grafana

 系统监控:Prometheuszabbix

 负载均衡:Nginx

 网关:Kong,zuul

 链路追踪:Zipkin

 公司内部文档:Confluencenextcloud

 Web服务器:Nginx、Tomcat

 数据库:OracleMysqlredis

产品和UI图:蓝湖。

公司内部文档:Confluence Wiki。

 报警:各种机器人api推送到工作群

 这个图来自网络,可以看到这过程中有哪些组件应用参与其中

 

个人理解,想实现DevOPs就得形成一套标准的持续集成部署流水线,没有一套好的流水线,实现DevOps是空中楼阁,至于典型的CICD流水线过程,略

end

posted @   siemens800  阅读(83)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 我与微信审核的“相爱相杀”看个人小程序副业
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
点击右上角即可分享
微信分享提示