升级打怪之路：中小企业的持续部署总结和避坑指南

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

持续的干货三大块：

• 代码管理
• 代码编译打包
• 代码发布

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

1. 研发环境。研发自己搞，爱怎折腾就怎么折腾。
2. 测试环境。测试验证的环境，可以甲乙丙丁多个存在。
3. 生产镜像环境。预发布用，缓冲不可控因素。
4. 生产环境。顾名思义。

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

代码管理

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

Git工作流

从推动力上来说，研发团队的推动力来自产品和市场。这个在写公司 Scrum 流的文章里有提及。

这个地方就不啰嗦git的工作流了。我们遵从了Gitflow工作流的基本逻辑。实际运用中灵活处理。

想了解 Git 的工作流请移步 github 上的 git-workflows-and-tutorials。

数据库变更管理

数据库是最难控制变更的。因此我们经过探索和总结摸索了一套较为有效的管理方式。可能还不是最科学的，虽然会有些问题，但是目前运作问题不算大。

也很少看到这方面的文章。我们约定，数据库变更以脚本方式提交，禁止研发在测试环境自己修改数据库，变更需提交脚本作为依据。那么，我在执行过程中，如测试环境A，跑了，我就会以修改文件夹名称，以名称为标记。

如果脚本还要再修改，则研发口头告知或他直接提交新的变更脚本。变更脚本有若干个，通常以任务标号为命名规则，没有项目标号则按自定义方式定义。

这套机制，实施最大的难度是协调，让研发了解这个规则。了解并熟悉这套流程之后，基本就没有什么大问题。

编译打包发布测试环境

现在这一套全部脚本化，总结就是流程是逐步完善起来的，一个阶段有一个阶段的做法。

开始，研发手动在本地打包，工具 eclipse+maven，打包完后手动上传到服务器的 tomcat 指定目录。那会我们只有３个项目，这么做问题不大。

后来，总是等着研发发布，太慢了，这么low的重复劳动我说我来做好了，你教下我怎么打包的，然后我就会了，我就研究了maven的一起机制。搞了那么一周多点，由于拿到了测试服务器的账户密码，我就在想怎么可以提高效率。

研究了明白了里面的原理，我就很自然的认为，既然本地可以打包，那服务器上到打包拷贝过去不是更快，网络传输的时间就略去了。于是，我测试了下，填了很多坑，手动在服务器上打包发布成功。就掌握了最原始的发布。

再后来，项目越来越多，多到大于 10 个，虽然只有几个发布频率很高，但是手动发布感觉劳心费力，效率底下，我就琢磨如何提高。shell 就引入。项目进度太快，我根本没有时间利用上班时间搞，于是下班后，自己一点一点测试。

把第一版的自动发布脚本写出来，结合 crontab 命令，每天自动发布。然后就轻松多了。后来专门利用业余时间对shell 做了一个深化，就有了一次重构。

现在使用的脚本已经不是这个版本了，又被我重构了一次。由之前的一锅贴全部发布，改进为任意项目选择发布，由 Jenkins 驱动。现在的模式：自动＋手动方式。比起从前还是大大的加快了迭代测试效率。虽然还有很多问题。比如现在的不熟结构是所有项目都在一个tomcat下面，发布一个，其实是影响全局的。全套发布下来，花了很多不必要的时间。

当然，还写了很多发布小工具，比如自动识别24小时内修改提交到代码库的 js/css/jsp 等静态资源文件，敲个命令自动拷贝过去，完全不用重新打包。

还存在的问题：

1. tomcat 部署在一起导致的发布启动效率，浪费不必要的时间。主要是系统资源不够，没有去拆分。
2. 外网地址一周要变２－３次，需要手动去修改域名映射。浪费时间。
3. Jenkins 让人人都具备发布能力，从某种意义上来说是不恰当的。 虽然解放了我，但是还是存在相互干扰的情况。不算严重。

发布生产

测试完成就发生产。

这个也是一个迭代过程。迭代到目前，重要核心项目都有多个节点。服务端使用了负载均衡。负载均衡是第三方服务，目前无法脚本自动化，所以除了核心的几个节点外，其他脚本发布。

核心节点，是第三方上断掉某节点，然后手动执行发布。发布后，再把节点放回去。接着另一个节点，基本上做到了热发布。

目前的问题：

1. 手动发布的没有要手动做备份。
2. 核心节点的手动发布效率不敢恭维，但是得接受，因为生产，不能出事故。
3. 热修代码提交没有得到控制。已经出台提交代码规约去限制。
4. 发布后的验证。

整个流程的不足和展望

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

展望，就是解决不足。

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

来源：https://blog.csdn.net/windanchaos/article/details/78604321?spm=1001.2014.3001.5501