DevOps实践面临的挑战

前言

本文记录了作者在带领团队进行DevOps实践中面临的挑战。

很多挑战在一些组织中可能无法理解，但是它们却是真实的存在。

DevOps实践面临的挑战

没有类生产环境作测试

没有足够的机器来部署类生产环境，特别是生产环境是集群环境时，需要多台机器才能搭建类生产环境。

什么都不让装

由于”安全“、”合规“等各种原因，机器上不允许安装”不合规“的软件，偏偏DevOps工具链需要安装这些软件和工具；另外一种情况是没有root账号权限，想装也装不了。

老工具不好用，新工具不会用

比如，还用SVN，用过Git，不会用，合并代码时搞错了，以后都不敢用Git了。

两地办公，网络不通

一边在客户现场，一边在公司，两边网络不通，导致代码合并复杂、繁琐且易出错。

太忙了，没空改进

天天在救火，没空预防火灾。

可是中国有句俗话，磨刀不误砍柴功。

要的是结果，不是过程

看重结果，看重回款，看重客户。

但是没有过程，哪来的结果？

网络太慢，服务器不能访问外网

服务器不能访问外网，离线安装工具时，需要手工解决包依赖，非常痛苦。

网络太慢，用笔记本电脑上网或下载工具也是很慢。

不愿意写单元测试

就是觉得写单元测试太耗时间，不愿意写。

结果就是部署到生产环境后，要花更多时间Debug。

外包项目

给甲方作的外包项目，项目做完了，团队也解散，团队成员被重新组合到新的项目团队中了。

DevOps工具链安装到甲方的机器里面，换了个甲方，一切还要从头开始。

不求有功，但求无过

愿意做出改变的人，没有决策权；有决策权的人，不愿意做出改变。

结果就是团队成员都抱有”不求有功，但求无过“的心态。

不做code review

不做code review，代码不通过merge request或pull request 而是被直接push到公共分支。

借口是做code review浪费时间。

代码不合并回master

在一些长期存在的特性分支上开发，比如在dev分支上开发，从prod分支部署，但是却没有合并回master。

当然如果将prod分支理解成master，也可以说的通。

但是prod分支在这里更像是release分支。