×

扫描二维码登录本站

标签: 暂无标签
DevOps一种概念、一种思想,很难界定说DevOps该做什么,不该做什么。
在工作的过程中,我从来没有向团队同事提起过DevOps这个单词。这个新型英语单词的发音/devɒps/,就算发音准确了,你还得跟别人再拼读一次D.E.V.O.P.S ;拼读完了,还得介绍它是Development Operations的简称;接下来还要跟他们介绍什么含义。这不但显得自己装逼,还卖概念卖理论搞得别人晕头转向,让别人不知道怎么回事。
日常中,一般沟通时,更多是用“自动化”这个词,自动化编译、自动化部署、自动化发布等等。对普通非技术类人员来说(比如游戏项目里的策划和美术),虽然还没听过DevOps这个概念,但其实已经应用在自己的日常工作中了。
实施
我对效率工具热爱,在开发的工具中处处追求自动化来提高生产力,这是前Unity游戏项目(2014-2015年)的一个DevOps工具链的尝试:
简单说下日常自动化流水线:
Redmine:任务的管理,工作的分配;由项目经历、游戏策划进行工作调度,在工作完成后,为任务标记上“待测试”,进入测试状态;在测试完成后,标记“已测试”,以维持基本的日常任务进度。
Subversion(SVN):作为团队开发的基础,各人的工作按照规范往上进行提交;包括程序、策划和美术工作成果,都往SVN版本库上传。
Jenkins:当SVN提交完成后,触发钩子,进行编译工作;(另有每晚凌晨定时)除编译工作以外,Jenkins还会承担各种有自动化需求的工作,如测试环境的部署。 它是开发、运维连接的核心桥梁。
私有云虚拟机:当Jenkins完成编译工作后,立刻在内网部署服务器并启动;
软件仓库:到这里已经验证提交的结果能正常运行了,将产物放到软件仓库归档;本质上它其实就是一个简单的http文件服务器,可以通过浏览器(如h5ai等插件)来查看和管理文件。
Supervisord:启动的服务器的进程管理;它有监控功能,能监视进程的健康状况。
ELK:ElasticSearch+LogStack+Kibana,日志的收集和查询;所有的游戏客户端日志,都会通过UDP的方式,上传到ELK日志系统。在日常第三方出现问题是,能通过该日志系统快速定位问题。
测试验收:回到Redmine,根据任务的内容,把它当做测试用例来测试;
Ansible:自动化配置、运维,从软件仓库获取软件,对多台机器进行批量部署;
FIR.im:部署外网,外网也可以体验到最新Demo;
至此一次成功的发布完成了,这种发布,每天都会进行无数次。任意环节失败了,会发送邮件进行预警,看是谁的锅。
老实说,其实最初使用Jenkins+Redmine+Ansible等工具链的时候,我们还不知道“DevOps”这个名堂,是后来才了解这个概念的。可以说,当时推行“自动化”这个出发点开始使用各种自动化工具的时候,已经逐渐的走上DevOps的路了。
改变
DevOps带给开发团队怎样的改变? 举一些刚入行的经历:
一个游戏项目里,有程序、策划、美术的分工。那时候,一个美术完成他们的场景编辑后,会用Unity打包一个Package,发给某一个策划;策划同学,收到这个Package,导入到Unity,然后整理场景格式,之后进行Asset Bundle导出,并进行SVN的提交。这时候程序同学,更新到SVN下来,发现Asset Bundle资源是错的,跟策划同学说;策划同学跑去跟美术同学说,美术同学修复;美术修复完了,再打Package,又给策划同学........(循环,一天过去了)。
经过一个月的开发,我们要发布新版本的IPA程序了,已经有一个月的时间,没有编译过最终产品了,不知道编译是否顺利。这时候,老大一声下令,把SVN锁了,然后打开Unity,手工编译Xcode工程; 但是发现有一个依赖库问题,修复,再手工编译,又发现一个BUG,再重新来...........(循环,一天过去了)
要发布一个DEMO给外网的合作,一个熟悉Linux负责测试的同学,开始在Linux上手工进行编译,然后SSH上去服务器,上传服务器文件,执行各种命令,进行服务器的启动、停止。  哦,发现一个BUG,要马上改,改完了,重复之前说的步骤..........(循环,一天过去了)
如今看起来啼笑皆非的重复劳动力,当时是确确实实的存在的。入行之初我就对这些现象非常的震惊,我万万没想到做程序员的人居然是这个样子的。 这也是后来在主导的项目中引入了这些工具链,也算是DevOps的实施尝试吧。
是否引入DevOps思想或DevOps相关工具链,这对一个开发团队的影响是十分的深的,这不光体现在编译、运维,甚至还会影响开发人员的编程风格 —— DevOps思想强调自动化,而编程的过程中,一些重复累赘的代码也是应该通过自动化来解决的。
未来
在我看来,引入DevOps工具链可以节省成吨的成本:包括时间成本,人力成本。 实施DevOps前,从上面的案例中可以看到,其实每个工具,都可能需要一个特定的人来完成的,工作量分布下去,可不是一件小事情了,很容易就让人在坑中度过漫长岁月。
跟之前相比,现阶段所整合实施工具就更多了,比如:
DockerZabbixSentryRundeck等等等。
在我看来,这个领域还有一个杀手级的应用程序可以发展,可以把这一切整合一起的,它应该是一个类似Jenkins这种任务流的产品,并比它更好用,更完善的GUI。个人之力无法实现,只能期待未来有这样的产品出现——也许,这个产品,就是人工智能的催化产物。
DevOps企业
与以前相比,这些工具链,也不一定事必躬亲,已经有很多的云计算企业有这方便的帮助了:
o    DaoCloud - 业界领先的容器云平台
o    网易蜂巢-新一代云计算平台
o    华为开发云
这类产品本身是非常好的,但要让这种思想让普通人都容易理解,才能让它们真正的普及、整合起来。 传播、布道是关键。(陈霖霖原创





上一篇:给DevOps贴上最佳实践的标签
下一篇:DevOps 的前世今生文化
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by ITIL  © 2001-2025
返回顶部