代码管理

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

git工作流

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

数据库变更管理

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

编译打包发布测试环境

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

发布生产

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

整个流程的不足和展望

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

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

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