我是做DevOps这个领域的创业者，跟一些中小互联网和传统IT公司都有过这方面的一些探讨。

现在对实施DevOps有想法的公司，多半都是业务发展还不错，在研发和运维上都比较大的压力的公司，希望通过引入DevOps来提升公司IT部门的总体运作效率，来支撑业务的发展速度。

关于DevOps对效率的提升，Puppet出过一份调研报告，算是比较成体系的。
中文版的报告链接在此：[  /?target=http%3A// /download/devops-report]download/devops-report[/url]

工欲善其事，必先利其器，现在大家在DevOps领域最关注的还是在工具层面。
下面是我跟这么多公司接触下来，大家使用比较多的工具：
1、监控工具
比较老牌的就是Zabbix,Nagios，用Zabbix的感觉是最多的。
国内的有小米开源的OpenFalcon。
这类监控工具一般是对服务器、服务（中间件，数据库）做一些常用指标的监控。

2、性能分析/APM工具
APM很多时候被认为是监控的一个细分领域。
但在现代复杂分布式系统架构下，APM工具往往更能准确、直接的帮助用户定位到性能瓶颈，比如哪一个URL访问慢、哪一个方法执行慢、哪一个SQL执行慢。

在以往要想拿到这些数据，往往得需要比较资深的架构师、DBA一起合作才能拿到这些数据，而定位瓶颈的效率往往还不太高。
现在通过APM工具能让普通技能的运维人员，也很高效的定位到这些深层的问题。

现在商用的APM工具不少，国外的有Newrelic，国内知名的就有听云、Oneapm、透视宝这些。
开源的也有Pinpoint（naver开源）、Zipkin（twitter开源）、CAT（大众点评开源）.

3、批量+自动化运维工具
这里就比较多了，知名的有Puppet、Ansible、Chef、Saltstack这些。
这些在网上的资料也比较多，找比较新版本的官方文档看就行了。

Puppet和chef是比较早期的工具，受众面也很大，不过这两个工具基于ruby实现，现在要找到熟悉ruby的人来做这块的二次开发可不容易。
而ansible和saltstack则相对新生代一些，目前用户基数增长很快，基于python实现，要找做二次开发的人也相对容易的多。

4、集中日志分析工具
在一个服务器比较多的环境下，如何集中的管理和分析、查询日志，已经变成一个比较强的需求了。
想象一下，如果发生了某个错误，你还得一台台机器去翻日志文件，是不是很蛋疼。
在这个需求驱动下，就诞生了一些集中日志分析工具。

在开源领域，比较知名的就是ELK这一套工具了，涵盖了日志采集、上报、搜索、展现这一类基本需求，现在比较多的上规模的企业都用这个，网上资料也大把。
核心实现机制都是通过一些日志采集代理（类似Filebeat）去爬日志文件，将最新的部分提交到采集服务端，后端再对接搜索引擎，能支持很快速、准确的搜索即可。

有一个国内不怎么知名的Sentry日志收集服务，比较轻量级，本身是Python做的，与各种语言的日志框架做了非常好的集成，可以很方便的集中收集异常日志，并分配给对应的开发人员。
它在github上有10000多个star了，这在DevOps相关的软件里，都是排名非常靠前的了。
git的地址：[  /?target= /getsentry/sentry]GitHub - getsentry/sentry: Sentry is cross-platform crash reporting built with love[/url]

5、持续集成/发布工具
我接触的人都是用Jenkins的，没有用其他的，可能跟我所在的技术圈子有关。

集成打包的过程其实一般都比较简单，配好版本库和打包脚本就行。
但发布的过程就比较复杂，有些是全量发布，但也有非常多的IT团队采用增量发布。
这个方面如果想用工具，还是得先分析清楚现有的发布流程，手工情况下怎么做，哪些能通过自动化工具来完成。

6、IaaS集成
最近两年的公有云推广比较迅速，很多新的服务器采购都被导入到云上去了。
现在主流的公有云都提供了比较完备的API，基于这些API也可以做一些针对基础资源的自动化操作，比如游戏行业的快速开服。





作者：卖鱼的小白菜
链接：[  /question/24413538/answer/145048082]question/24413538/answer/145048082[/url]
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

DevOps在移动应用开发中的应用，以 iOS 开发为例

DevOps 是什么呢？

我们先来看一张图

<img src="" data-rawwidth="1300" data-rawheight="1268" class="origin_image zh-lightbox-thumb" width="1300" data-original="">

Dev, QA, Ops 的交汇处我们认为就是 DevOps。 实际上说白了，DevOps 就是把产品开发过程中各部门交汇处的活给干了，让各部门都专注于干他们自己的活儿。

依稀记得，刚进公司的时候，每天工作的大头就是给 QA， TA， PM, Boss编译各种版本的包，真正写代码的时间寥寥无几 :(

<img src="" data-rawwidth="252" data-rawheight="220" class="content_image" width="252">

实际上，做过移动应用开发的都知道，iOS 需要很多版本，inHouse, Adhoc, AppStore, 以及QA还需要各种不同的环境来测试相对应的功能，TA（自动化测试）也要各种版本，每个开发还需要自己独立的分支版本交付QA测试等。

尤其是我们团队采用的是 scrum 开发模式，基本每两星期就是一个迭代，上述的工作非常繁琐，重复性又大，Dev基本上每天都在被逼着给build，QA，TA，PM又在着急的等着build，每个人都怨气满满。

<img src="" data-rawwidth="264" data-rawheight="220" class="content_image" width="264">

为了防止各方互相扔屎 ：）， 我们很快购买了一台 Mac Pro 作为编译服务器，在上面部署了Jenkins2.0。

V1.0 Jenkins Job只有几种类型，Inhouse，Adhoc，AppStore等几种最基本的Job

因为iOS不同的编译类型需要不同的证书，为了方便，我们把不同的证书打包成 diff 文件，

下图中这些不同后缀的Job 的配置中，会apply相对应的diff文件

<img src="" data-rawwidth="690" data-rawheight="396" class="origin_image zh-lightbox-thumb" width="690" data-original="">

此时虽然各方已经不互相扔 shit 了，但还在互喷，主要问题在于Jenkins经常挂掉，而开发又没有及时去fixed。原因是在于我们的 App 集成了crash监控服务crittercism，它可以做到实时监控crash数据，汇报新的crash。但是开发每次都需要手动上传DSYM文件，很是麻烦。虽然我们用了Jenkins插件自动集成，不过Jenkins插件的支持很不好，经常在上传DSYM的时候GG。到了后面我们自己也忍不了了，就自己写了上传DSYM的脚本。

考虑到TA还需要自定义产品环境，App动态的版本号和 git commit 号等，我们就直接将所有的配置都用 python,shell 脚本实现，实现了基于Jenkins Job名字的自动化配置。

App编译结束后，我们会自动将生成的 IPA 包发布到所需要的渠道，我们使用HockeyApp自动发布和自动推送，而针对国内的网速，则是使用了[  /?target=http%3A//fir.im]h [/url] .

还有针对Adhoc/App Store的上传TestFlight的神器，叫fastlane，其中Gym和Deliver两大神器结合使用最牛逼。可以全自动上传App Store，不仅傻瓜化好用，而且还带push notification功能。(该功能慎用，至于为什么自己去搜咯 ：)

放出小部分脚本代码

#jenkins environment variablejenkinsJOB_NAME = os.environ.get('JOB_NAME', '') ## MEANS This is running in jenkins ,not localif jenkinsJOB_NAME:#os.system("git reset --hard HEAD") #need run this in jenkins shell, otherwise will discard user's committed code   isInhouse = jenkinsJOB_NAME.lower().find("inhouse")   isHockeyApp = jenkinsJOB_NAME.lower().find("hockeyapp")   isAdhoc = jenkinsJOB_NAME.lower().find("adhoc")   isDevelopment = jenkinsJOB_NAME.lower().find("development")   isAppStore = jenkinsJOB_NAME.lower().find("appstore")   isTaXMN = jenkinsJOB_NAME.lower().find("ta-xmnlab")

经过好几次的升级之后，现在Jenkins Job基本都比较稳定了，如果某个开发需要提供自己所开发功能的build， 只需要 copy一份相对应的Job 配置， 改掉代码指向，就可以了，前后花费时间不超过 30s，甚至QA在需要的时候也可以自己手动触发Job编译自己需要的Build。从那以后，我明显能够感觉到漂亮的 QA妹子花在 Dev 单身狗身上的时间更少了，说好的天天喊我给Build的呢。

我们在Job的name 中加了一个 LED 的关键字，如果Job 编译成功了，绿灯，啥事也没有，但是，要是Job挂了，这个就会滴滴滴地响，你可以想象一下，在Jenkins上建几十个Job，然后让每个Job都挂掉，那真是蛙声一片。

不过这个还是得看个人需要吧，我们目前只有两个Job配置了这种高端货，并且只有失败的第一次会响三声。

来，赞一下：）

==============================================================

作者：陈小霖 Kelly
链接：[  /question/24413538/answer/139454464]question/24413538/answer/139454464[/url]
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

DevOps一种概念、一种思想，很难界定说DevOps该做什么，不该做什么。

在工作的过程中，我从来没有向团队同事提起过“DevOps”这个单词。这个新型英语单词的发音/devɒps/，就算发音准确了，你还得跟别人再拼读一次D.E.V.O.P.S ；拼读完了，还得介绍它是Development Operations的简称；接下来还要跟他们介绍什么含义。这不但显得自己装逼，还卖概念卖理论搞得别人晕头转向，让别人不知道怎么回事。

日常中，一般沟通时，更多是用“自动化”这个词，自动化编译、自动化部署、自动化发布等等。对普通非技术类人员来说（比如游戏项目里的策划和美术），虽然还没听过DevOps这个概念，但其实已经应用在自己的日常工作中了。

实施

我对效率工具热爱，在开发的工具中处处追求自动化来提高生产力，这是前Unity游戏项目（2014-2015年）的一个DevOps工具链的尝试：

<img src="" class="content_image">

查看大图：[  /?target= /v2-3670fc84c0a1c3215c7f8a1540c308cc.png]v2-3670fc84c0a1c3215c7f8a1540c308cc.png[/url]

简单说下日常自动化流水线，

Redmine：任务的管理，工作的分配；由项目经历、游戏策划进行工作调度，在工作完成后，为任务标记上“待测试”，进入测试状态；在测试完成后，标记“已测试”，以维持基本的日常任务进度。

Subversion(SVN)：作为团队开发的基础，各人的工作按照规范往上进行提交；包括程序、策划和美术工作成果，都往SVN版本库上传。

Jenkins：当SVN提交完成后，触发钩子，进行编译工作；（另有每晚凌晨定时）除编译工作以外，Jenkins还会承担各种有自动化需求的工作，如测试环境的部署。 它是开发、运维连接的核心桥梁。

私有云虚拟机：当Jenkins完成编译工作后，立刻在内网部署服务器并启动；

软件仓库：到这里已经验证提交的结果能正常运行了，将产物放到软件仓库归档；本质上它其实就是一个简单的http文件服务器，可以通过浏览器（如h5ai等插件）来查看和管理文件。

Supervisord：启动的服务器的进程管理；它有监控功能，能监视进程的健康状况。

ELK：ElasticSearch+LogStack+Kibana，日志的收集和查询；所有的游戏客户端日志，都会通过UDP的方式，上传到ELK日志系统。在日常第三方出现问题是，能通过该日志系统快速定位问题。

测试验收：回到Redmine，根据任务的内容，把它当做测试用例来测试；

Ansible：自动化配置、运维，从软件仓库获取软件，对多台机器进行批量部署；

[  /?target=http%3A//FIR.im]FIR.im[/url]：部署外网，外网也可以体验到最新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前，从上面的案例中可以看到，其实每个工具，都可能需要一个特定的人来完成的，工作量分布下去，可不是一件小事情了，很容易就让人在坑中度过漫长岁月。

跟之前相比，现阶段所整合实施工具就更多了，比如：

Docker、Zabbix、Sentry、Rundeck等等等。

在我看来，这个领域还有一个杀手级的应用程序可以发展，可以把这一切整合一起的，它应该是一个类似Jenkins这种任务流的产品，并比它更好用，更完善的GUI。个人之力无法实现，只能期待未来有这样的产品出现——也许，这个产品，就是人工智能的催化产物。

原创：刀把五

我是做DevOps这个领域的创业者，跟一些中小互联网和传统IT公司都有过这方面的一些探讨。

现在对实施DevOps有想法的公司，多半都是业务发展还不错，在研发和运维上都比较大的压力的公司，希望通过引入DevOps来提升公司IT部门的总体运作效率，来支撑业务的发展速度。

关于DevOps对效率的提升，Puppet出过一份调研报告，算是比较成体系的。
中文版的报告链接在此：[  /?target=http%3A// /download/devops-report]download/devops-report[/url]

工欲善其事，必先利其器，现在大家在DevOps领域最关注的还是在工具层面。
下面是我跟这么多公司接触下来，大家使用比较多的工具：
1、监控工具
比较老牌的就是Zabbix,Nagios，用Zabbix的感觉是最多的。
国内的有小米开源的OpenFalcon。
这类监控工具一般是对服务器、服务（中间件，数据库）做一些常用指标的监控。

2、性能分析/APM工具
APM很多时候被认为是监控的一个细分领域。
但在现代复杂分布式系统架构下，APM工具往往更能准确、直接的帮助用户定位到性能瓶颈，比如哪一个URL访问慢、哪一个方法执行慢、哪一个SQL执行慢。

在以往要想拿到这些数据，往往得需要比较资深的架构师、DBA一起合作才能拿到这些数据，而定位瓶颈的效率往往还不太高。
现在通过APM工具能让普通技能的运维人员，也很高效的定位到这些深层的问题。

现在商用的APM工具不少，国外的有Newrelic，国内知名的就有听云、Oneapm、透视宝这些。
开源的也有Pinpoint（naver开源）、Zipkin（twitter开源）、CAT（大众点评开源）.

3、批量+自动化运维工具
这里就比较多了，知名的有Puppet、Ansible、Chef、Saltstack这些。
这些在网上的资料也比较多，找比较新版本的官方文档看就行了。

Puppet和chef是比较早期的工具，受众面也很大，不过这两个工具基于ruby实现，现在要找到熟悉ruby的人来做这块的二次开发可不容易。
而ansible和saltstack则相对新生代一些，目前用户基数增长很快，基于python实现，要找做二次开发的人也相对容易的多。

4、集中日志分析工具
在一个服务器比较多的环境下，如何集中的管理和分析、查询日志，已经变成一个比较强的需求了。
想象一下，如果发生了某个错误，你还得一台台机器去翻日志文件，是不是很蛋疼。
在这个需求驱动下，就诞生了一些集中日志分析工具。

在开源领域，比较知名的就是ELK这一套工具了，涵盖了日志采集、上报、搜索、展现这一类基本需求，现在比较多的上规模的企业都用这个，网上资料也大把。
核心实现机制都是通过一些日志采集代理（类似Filebeat）去爬日志文件，将最新的部分提交到采集服务端，后端再对接搜索引擎，能支持很快速、准确的搜索即可。

有一个国内不怎么知名的Sentry日志收集服务，比较轻量级，本身是Python做的，与各种语言的日志框架做了非常好的集成，可以很方便的集中收集异常日志，并分配给对应的开发人员。
它在github上有10000多个star了，这在DevOps相关的软件里，都是排名非常靠前的了。
git的地址：[  /?target= /getsentry/sentry]GitHub - getsentry/sentry: Sentry is cross-platform crash reporting built with love[/url]

5、持续集成/发布工具
我接触的人都是用Jenkins的，没有用其他的，可能跟我所在的技术圈子有关。

集成打包的过程其实一般都比较简单，配好版本库和打包脚本就行。
但发布的过程就比较复杂，有些是全量发布，但也有非常多的IT团队采用增量发布。
这个方面如果想用工具，还是得先分析清楚现有的发布流程，手工情况下怎么做，哪些能通过自动化工具来完成。

6、IaaS集成
最近两年的公有云推广比较迅速，很多新的服务器采购都被导入到云上去了。
现在主流的公有云都提供了比较完备的API，基于这些API也可以做一些针对基础资源的自动化操作，比如游戏行业的快速开服。





作者：卖鱼的小白菜
链接：[  /question/24413538/answer/145048082]question/24413538/answer/145048082[/url]
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

DevOps在移动应用开发中的应用，以 iOS 开发为例

DevOps 是什么呢？

我们先来看一张图

<img src="" data-rawwidth="1300" data-rawheight="1268" class="origin_image zh-lightbox-thumb" width="1300" data-original="">

Dev, QA, Ops 的交汇处我们认为就是 DevOps。 实际上说白了，DevOps 就是把产品开发过程中各部门交汇处的活给干了，让各部门都专注于干他们自己的活儿。

依稀记得，刚进公司的时候，每天工作的大头就是给 QA， TA， PM, Boss编译各种版本的包，真正写代码的时间寥寥无几 :(

<img src="" data-rawwidth="252" data-rawheight="220" class="content_image" width="252">

实际上，做过移动应用开发的都知道，iOS 需要很多版本，inHouse, Adhoc, AppStore, 以及QA还需要各种不同的环境来测试相对应的功能，TA（自动化测试）也要各种版本，每个开发还需要自己独立的分支版本交付QA测试等。

尤其是我们团队采用的是 scrum 开发模式，基本每两星期就是一个迭代，上述的工作非常繁琐，重复性又大，Dev基本上每天都在被逼着给build，QA，TA，PM又在着急的等着build，每个人都怨气满满。

<img src="" data-rawwidth="264" data-rawheight="220" class="content_image" width="264">

为了防止各方互相扔屎 ：）， 我们很快购买了一台 Mac Pro 作为编译服务器，在上面部署了Jenkins2.0。

V1.0 Jenkins Job只有几种类型，Inhouse，Adhoc，AppStore等几种最基本的Job

因为iOS不同的编译类型需要不同的证书，为了方便，我们把不同的证书打包成 diff 文件，

下图中这些不同后缀的Job 的配置中，会apply相对应的diff文件

<img src="" data-rawwidth="690" data-rawheight="396" class="origin_image zh-lightbox-thumb" width="690" data-original="">

此时虽然各方已经不互相扔 shit 了，但还在互喷，主要问题在于Jenkins经常挂掉，而开发又没有及时去fixed。原因是在于我们的 App 集成了crash监控服务crittercism，它可以做到实时监控crash数据，汇报新的crash。但是开发每次都需要手动上传DSYM文件，很是麻烦。虽然我们用了Jenkins插件自动集成，不过Jenkins插件的支持很不好，经常在上传DSYM的时候GG。到了后面我们自己也忍不了了，就自己写了上传DSYM的脚本。

考虑到TA还需要自定义产品环境，App动态的版本号和 git commit 号等，我们就直接将所有的配置都用 python,shell 脚本实现，实现了基于Jenkins Job名字的自动化配置。

App编译结束后，我们会自动将生成的 IPA 包发布到所需要的渠道，我们使用HockeyApp自动发布和自动推送，而针对国内的网速，则是使用了[  /?target=http%3A//fir.im]h [/url] .

还有针对Adhoc/App Store的上传TestFlight的神器，叫fastlane，其中Gym和Deliver两大神器结合使用最牛逼。可以全自动上传App Store，不仅傻瓜化好用，而且还带push notification功能。(该功能慎用，至于为什么自己去搜咯 ：)

放出小部分脚本代码

#jenkins environment variablejenkinsJOB_NAME = os.environ.get('JOB_NAME', '') ## MEANS This is running in jenkins ,not localif jenkinsJOB_NAME:#os.system("git reset --hard HEAD") #need run this in jenkins shell, otherwise will discard user's committed code   isInhouse = jenkinsJOB_NAME.lower().find("inhouse")   isHockeyApp = jenkinsJOB_NAME.lower().find("hockeyapp")   isAdhoc = jenkinsJOB_NAME.lower().find("adhoc")   isDevelopment = jenkinsJOB_NAME.lower().find("development")   isAppStore = jenkinsJOB_NAME.lower().find("appstore")   isTaXMN = jenkinsJOB_NAME.lower().find("ta-xmnlab")

经过好几次的升级之后，现在Jenkins Job基本都比较稳定了，如果某个开发需要提供自己所开发功能的build， 只需要 copy一份相对应的Job 配置， 改掉代码指向，就可以了，前后花费时间不超过 30s，甚至QA在需要的时候也可以自己手动触发Job编译自己需要的Build。从那以后，我明显能够感觉到漂亮的 QA妹子花在 Dev 单身狗身上的时间更少了，说好的天天喊我给Build的呢。

我们在Job的name 中加了一个 LED 的关键字，如果Job 编译成功了，绿灯，啥事也没有，但是，要是Job挂了，这个就会滴滴滴地响，你可以想象一下，在Jenkins上建几十个Job，然后让每个Job都挂掉，那真是蛙声一片。

不过这个还是得看个人需要吧，我们目前只有两个Job配置了这种高端货，并且只有失败的第一次会响三声。

来，赞一下：）

==============================================================

作者：陈小霖 Kelly
链接：[  /question/24413538/answer/139454464]question/24413538/answer/139454464[/url]
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

DevOps一种概念、一种思想，很难界定说DevOps该做什么，不该做什么。

在工作的过程中，我从来没有向团队同事提起过“DevOps”这个单词。这个新型英语单词的发音/devɒps/，就算发音准确了，你还得跟别人再拼读一次D.E.V.O.P.S ；拼读完了，还得介绍它是Development Operations的简称；接下来还要跟他们介绍什么含义。这不但显得自己装逼，还卖概念卖理论搞得别人晕头转向，让别人不知道怎么回事。

日常中，一般沟通时，更多是用“自动化”这个词，自动化编译、自动化部署、自动化发布等等。对普通非技术类人员来说（比如游戏项目里的策划和美术），虽然还没听过DevOps这个概念，但其实已经应用在自己的日常工作中了。

实施

我对效率工具热爱，在开发的工具中处处追求自动化来提高生产力，这是前Unity游戏项目（2014-2015年）的一个DevOps工具链的尝试：

<img src="" class="content_image">

查看大图：[  /?target= /v2-3670fc84c0a1c3215c7f8a1540c308cc.png]v2-3670fc84c0a1c3215c7f8a1540c308cc.png[/url]

简单说下日常自动化流水线，

Redmine：任务的管理，工作的分配；由项目经历、游戏策划进行工作调度，在工作完成后，为任务标记上“待测试”，进入测试状态；在测试完成后，标记“已测试”，以维持基本的日常任务进度。

Subversion(SVN)：作为团队开发的基础，各人的工作按照规范往上进行提交；包括程序、策划和美术工作成果，都往SVN版本库上传。

Jenkins：当SVN提交完成后，触发钩子，进行编译工作；（另有每晚凌晨定时）除编译工作以外，Jenkins还会承担各种有自动化需求的工作，如测试环境的部署。 它是开发、运维连接的核心桥梁。

私有云虚拟机：当Jenkins完成编译工作后，立刻在内网部署服务器并启动；

软件仓库：到这里已经验证提交的结果能正常运行了，将产物放到软件仓库归档；本质上它其实就是一个简单的http文件服务器，可以通过浏览器（如h5ai等插件）来查看和管理文件。

Supervisord：启动的服务器的进程管理；它有监控功能，能监视进程的健康状况。

ELK：ElasticSearch+LogStack+Kibana，日志的收集和查询；所有的游戏客户端日志，都会通过UDP的方式，上传到ELK日志系统。在日常第三方出现问题是，能通过该日志系统快速定位问题。

测试验收：回到Redmine，根据任务的内容，把它当做测试用例来测试；

Ansible：自动化配置、运维，从软件仓库获取软件，对多台机器进行批量部署；

[  /?target=http%3A//FIR.im]FIR.im[/url]：部署外网，外网也可以体验到最新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前，从上面的案例中可以看到，其实每个工具，都可能需要一个特定的人来完成的，工作量分布下去，可不是一件小事情了，很容易就让人在坑中度过漫长岁月。

跟之前相比，现阶段所整合实施工具就更多了，比如：

Docker、Zabbix、Sentry、Rundeck等等等。

在我看来，这个领域还有一个杀手级的应用程序可以发展，可以把这一切整合一起的，它应该是一个类似Jenkins这种任务流的产品，并比它更好用，更完善的GUI。个人之力无法实现，只能期待未来有这样的产品出现——也许，这个产品，就是人工智能的催化产物。

原创：刀把五