0%

我公司目前的敏捷持续部署总结和展望

上一篇文章用了我2个晚上,今天把老早之前就想写的公司持续集成的总结和展望写了,算是给自己大脑一个交代——对自己说到做到。

持续的干货三大块:

为了规避风险,隔离不可控因素。三大块中又可以插入环境差异。通常是二到四个:

持续集成三大块,通常就在1\2\3环境里不停的迭代。最后到生产上被利用。生产迭代频率相对低一些。

代码管理

公司刚建立的时候用的是SVN,那个时代我还是个小白,并没有过多参与。后来,公司领导看git的分布式代码仓库牛掰,就在观望、学习、变革中,把代码管理的环境迁移到了git上面,这期间,团队经历了不适应,不会,抱怨,理解,能用,会用,善用的转变。主要还是招聘到了一个git小王子,他帮助团队对git的理解大踏步前进。废话讲完。

git工作流

git工作流
从推动力上来说,研发团队的推动力来自产品和市场。这个在写公司srum流的文章里有提及。
这个地方就不啰嗦git的工作流了。我们遵从了Gitflow工作流的基本逻辑。实际运用中灵活处理。
想了解git的工作流请移步github上的git-workflows-and-tutorials

数据库变更管理

数据库是最难控制变更的。因此我们经过探索和总结摸索了一套较为有效的管理方式。可能还不是最科学的,虽然会有些问题,但是目前运作问题不算大。也很少看到这方面的文章。我们约定,数据库变更以脚本方式提交,禁止研发在测试环境自己修改数据库,变更需提交脚本作为依据。那么,我在执行过程中,如测试环境A,跑了,我就会以修改文件夹名称,以名称为标记。如果脚本还要再修改,则研发口头告知或他直接提交新的变更脚本。变更脚本有若干个,通常以任务标号为命名规则,没有项目标号则按自定义方式定义。
这套机制,实施最大的难度是协调,让研发了解这个规则。了解并熟悉这套流程之后,基本就没有什么大问题。

编译打包发布测试环境

现在这一套全部脚本化,总结就是流程是逐步完善起来的,一个阶段有一个阶段的做法。
开始,研发手动在本地打包,工具eclipse+maven,打包完后手动上传到服务器的tomcat指定目录。那会我们只有3个项目,这么做问题不大。
后来,总是等着研发发布,太慢了,这么low的重复劳动我说我来做好了,你教下我怎么打包的,然后我就会了,我就研究了maven的一起机制。搞了那么一周多点,由于拿到了测试服务器的账户密码,我就在想怎么可以提高效率。研究了明白了里面的原理,我就很自然的认为,既然本地可以打包,那服务器上到打包拷贝过去不是更快,网络传输的时间就略去了。于是,我测试了下,填了很多坑,手动在服务器上打包发布成功。就掌握了最原始的发布。
再后来,项目越来越多,多到大于10个,虽然只有几个发布频率很高,但是手动发布感觉劳心费力,效率底下,我就琢磨如何提高。shell就引入。项目进度太快,我根本没有时间利用上班时间搞,于是下班后,自己一点一点测试。把第一版的自动发布脚本写出来,结合crontab 命令,每天自动发布。然后就轻松多了。后来专门利用业余时间对shell做了一个深化,就有了一次重构。
可以参考:http://blog.csdn.net/windanchaos/article/details/53490630
现在使用的脚本已经不是这个版本了,又被我重构了一次。由之前的一锅贴全部发布,改进为任意项目选择发布,由jenkins驱动。现在的模式:自动+手动方式。比起从前还是大大的加快了迭代测试效率。虽然还有很多问题。比如现在的不熟结构是所有项目都在一个tomcat下面,发布一个,其实是影响全局的。全套发布下来,花了很多不必要的时间。
当然,还写了很多发布小工具,比如自动识别24小时内修改提交到代码库的js/css/jsp等静态资源文件,巧个命令自动拷贝过去,完全不用重新打包。
还存在的问题:
1、tomcat部署在一起导致的发布启动效率,浪费不必要的时间。主要是系统资源不够,没有去拆分。
2、外网地址一周要变2-3次,需要手动去修改域名映射。浪费时间。
3、jenkins让人人都具备发布能力,从某种意义上来说是不恰当的。虽然解放了我,但是还是存在相互干扰的情况。不算严重。

发布生产

测试完成就发生产。
这个也是一个迭代过程。迭代到目前,重要核心项目都有多个节点。服务端使用了负载均衡。负载均衡是第三方服务,目前无法脚本自动化,所以除了核心的几个节点外,其他脚本发布。
核心节点,是第三方上断掉某节点,然后手动执行发布。发布后,再把节点放回去。接着另一个节点,基本上做到了热发布。
目前的问题:
1、手动发布的没有要手动做备份。
2、核心节点的手动发布效率不敢恭维,但是得接受,因为生产,不能出事故。
3、热修代码提交没有得到控制。已经出台提交代码规约去限制。
4、发布后的验证。

整个流程的不足和展望

1、环节上来说,缺乏自动化的测试,包含常规的代码检测,核心的api自动化测试。
2、上线后,核心功能需要人肉去验证,微信的ui自动化受阻。人肉总是不太稳定的,所以很多时候功能一多,一修改一个小地方,其他地方就受影响。
3、生产错误日志,没有很好的利用起来。现阶段,我人肉去tail and grep,排查错误,看到有问题的直接喊研发到我那看,这个工作没有人喊我做,但是必要。而错误日志很多是没有必要打印的,这也是一个可以优化的。

展望,就是解决不足。
1、这个不是我一个人能推动的事,需要团队配合。
2、已有计划推动自动化的一些使用。
3、日志监控系统,搭一套。开源软件。后期(很远很远)就是线上监控。
4、安全测试的还比较少。所以可以搞一搞,安全扫描工具。
5、代码的静态扫描也要搞起来,研发现在是反感态度,空指针……
6、内网从新搭建测试环境。tomcat分开部署。