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前，从上面的案例中可以看到，其实每个工具，都可能需要一个特定的人来完成的，工作量分布下去，可不是一件小事情了，很容易就让人在坑中度过漫长岁月。

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

Docker、Zabbix、Sentry、Rundeck等等等。

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

DevOps企业

与以前相比，这些工具链，也不一定事必躬亲，已经有很多的云计算企业有这方便的帮助了：

o    DaoCloud - 业界领先的容器云平台

o    网易蜂巢-新一代云计算平台

o    华为开发云

这类产品本身是非常好的，但要让这种思想让普通人都容易理解，才能让它们真正的普及、整合起来。 传播、布道是关键。（陈霖霖原创）

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前，从上面的案例中可以看到，其实每个工具，都可能需要一个特定的人来完成的，工作量分布下去，可不是一件小事情了，很容易就让人在坑中度过漫长岁月。

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

Docker、Zabbix、Sentry、Rundeck等等等。

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

DevOps企业

与以前相比，这些工具链，也不一定事必躬亲，已经有很多的云计算企业有这方便的帮助了：

o    DaoCloud - 业界领先的容器云平台

o    网易蜂巢-新一代云计算平台

o    华为开发云

这类产品本身是非常好的，但要让这种思想让普通人都容易理解，才能让它们真正的普及、整合起来。 传播、布道是关键。（陈霖霖原创）