为了这篇文章，我前后写了将近十篇文章铺垫，才将这篇整体重构思想引出。

背景

先说下背景，我们是一家小公司，虽然打着做产品的旗帜，但是每个客户都有大量的个性化功能，这里指各个客户的java端、Android端、ios端(大部分功能代码是相同的，个性化功能代码不同)。我之前是做 Android的，实践证明，特殊情况下，只有我们Android组可以随意切换到任意一家客户，任意一版本的代码。并且修复一处公共bug，所有客户的版本都会更新。我也一直在介绍这种开发模式，但并得不到支持，直到年初，我晋升为移动端组长，加上，后来java组组长跳槽，我才有机会全面实施重构计划。

前言

因为我做过很多年的运维(网吧软硬件运维等)，对服务器硬件以及软件有较高的认识，加之我对各门语言有一定的开发经验，算是一位全栈工程师，对各端都比较熟悉。这一切，为我的实施带来了很大的帮助。本人申明以下所有重构思路均出自本人想法，实施上，由我统一安排培训后落实。(虽然落实阻力极大，但最终效果不错)

先说说效果

之前，我们每接入一个客户项目，完成java端、Android端、ios端和部署服务器环境等，需要2周的时间。现在，我们大概需要30分钟。并且每位客户个性化需求再多，我们也能灵活开发及切换到各个客户的代码上。之前，我们开发流程极为混乱，没有文档，没有各种开发流程，现在我们逐渐规范，至少节约50%的开发成本。当然，我们还在不断改善中。

Java 项目组

我们的java项目，原来分为接口服务、后台管理服务，但是都在一个git库里，我将它分为：

1. 接口服务

2. 后台服务

3. html5包

4. 公共包服务

因为本次重构，我逐步采用前后端分离方案，所以多出了h5包。

每个库分为多个分支，其中定义master为主分支，各个客户为新开的一个分支，通过分支来解决各个客户各种不同需求，(因为客户需求实在过细，有些文字都得改，单纯的插件化开发的话，每个插件都要n多个版本，这样对于我们小公司，做不起来)，当然各个客户也应该有个开发分支，但受限于我们人员较少，一期省去了开发分支，把本地暂存区作为开发分支。

开发流程如下：

开发人员只需要本地调试后，提交代码到git库的某个项目分支上，由Jenkins自动编译。

如果编译错误会通过邮件反馈到影响代码的开发人员邮箱中，另外测试人员一键部署后，测试出问题，也可以通过jira提单给开发人员。开发人员收到后，继续提交代码，不再像我们之前，必须通知开发人员，开发人员本地打包，这样无法跟踪项目代码。

补充：

因为我们项目比较多，人为维护版本号会费时费力，我决定一期采用Jenkins自动填入版本号到项目中，并在文件名中体现，所以，项目编译出的包可能是1.war、2.war、3.war，我们内部将其(1、2、3)作为版本号，当然war包内部我也写入了版本号。其次，我们剔除了大量含状态的代码，使得每个war在测试环境和生产环境自动加载不同配置来运行，因为无状态，所以war包、h5包在测试环境和生产环境都是一套代码。这里我们花了几周时间完成抽取无状态代码。

一键部署：
我们做了一套管理平台，可升级tomcat中间件下的各个war和h5。可以看看我们现在的效果：

主要功能如下：

1. 升级、显示当前版本

2. 对war包有效期，真实性校验

3. 开发人员将公共sql放入公共.sql里

4. 各个客户定制化需求的sql放入各个客户.sql里

每次只需要点后面的升级按钮，即可升级sql脚本或服务。
文章是之前写的，逻辑上有些变化，这里不做介绍。

客户端组

客户端开发流程，这里ios和Android一起说，我们提交代码后，Jenkins都会同时生产两套连接服务器地址不同的ipa、apk，这里因为很多情况在不同网络环境下需要看测试环境和生产环境，所以，我采用同时发2套包方案。

Android的同时2套包方案可参照我之前Android利用gradle同时编译多包(测试环境地址、生产环境地址)IOS同时发2套ipa包方案可参照我之前的IOS利用Xcode同时编译多包(测试环境地址、生产环境地址)在ios上架appstore流程上，我采用了半自动化发包策略，将其上传到开发者平台后，手动上架。各个客户，各个版本我们采用多分支的方案，和上文java同理，不同分支处理不同客户项目。

测试组

测试组流程

测试人员从jira提单后，开发人员解决后，会看到具体解决的版本号，然后进入oss存储，安装Android程序，或者ios程序，一键部署java项目。

而因为安卓和ios均是同时发2个包，java项目、h5项目无状态，所以生产环境和测试环境都可快速部署测试。

图中，以real文件名结尾的是连接生产环境地址。

项目经理

项目经理流程

我采用新客户新流程，老客户老流程，并逐步迁移到新流程中。其中执行数据库脚本已经被省略，由统一部署平台执行。

运维组

这张图是以前的逻辑，因为每个时期，每个客户给的服务器和服务器系统各不相同，运维起来极为复杂。我采用docker容器统一方案解决此问题，使得每个客户机器环境均相同。

下图我是我解决后的模型图：

我们把各个客户的服务器都整成docker集群，然后通过我们公司统一管理平台管理，然后将各个容器分配给不同的角色，这里我们是用Portainer来解决，并二次开发了一些需求。

这里的管理都不需要linux机器的密码，通过tls证书进行控制，而Windows机器将废弃不用。

该方案优点：

1. 在docker下，所有客户生产环境相同

2. 易于备份、迁移、恢复

3. 可建高可用环境，发包时采用灰度发包，蓝绿部署不中断服务

4. 可支持弹性伸缩设计，支持扩展

5. 支持负载均衡，域名转发，意外切换容器等

6. 有利于转型微服务架构

7. 快速搭建环境

而建立docker集群需要我们自动化完成，这里我采用了Ansible工具来实施，我们可通过指令分发，指令获取所有机器某个包的版本，执行不同的代码。

然后通过image镜像对客户进行统一部署容器，这里我们建立了私服。

私服篇

这里我建立了各种仓库，方便java开发，我建立了一个私有仓库，一个maven官方代理仓库，一个阿里云代理仓库；

docker上我为了方便开发打包其他环境，我创建了docker私有仓库；还有一些为了解决统一管理linux服务器而创建npm仓库；

以及安卓所要使用的gradle私有仓库，未来，我可能还会创建更多仓库，能支持的仓库列表都在下面：

大数据篇

大数据一直以来是很多公司核心产品，对于小公司，如何低成本实施呢，我研究了一套强大的大数据框架，并对其做了部分的二次开发。

接口篇

我全面统一采用restful风格api开发接口，接口文档自动生成，这里涉及几篇文章，暂时还没来得及写，后续补上。

文化篇

之前，我们开发需求完全依靠项目经理分配，现在我安排不断重构项目，带来了很多新的流程，这里征得领导同意，安排每周或每2周分别对各部门，培训后分配账号，实施。这个涉及公司内部业务，不便详说，敬请谅解。

后续

我写了几个月各方面的文章，大部分读者可能以为我是胡写一通。今天，终于把他们汇聚到一起，说实话，心情还是蛮激动的。

我承认我所有的重构对于很多大公司都是提不上台面的，但对于我们小公司，很多东西形成体系，说实话，真的很难。还有些内容，我不方便说，或者是忘记了说。事实上，我们做的远比文章里的内容要多得多。

还有，部分文章可能是几个月前写的，逻辑上和流程上，我们都已经做了很多优化和调整，但是主体思想都没有变，不影响阅读。

其次，我申明，本文中所有介绍，绝对不是最好的解决方案，很多方案是我对公司进行分析后定下的，绝不是每个小公司都适合。但我觉得本文一定能给你带来不少的灵感。

最后，本人能力有限，开发圈子也比较小，难免有考虑不周的地方，如果您有任何高见，欢迎告知，小生在此谢过大家。

作者：邵磊
链接：https://juejin.im/post/59e1d92d51882578db27c2e1

互联网、金融、通信 DevOps 转型落地经验，就在 GOPS 2020 · 深圳站

重磅！2020 年 DevOps 持续交付标准和技术运营标准评估报名正式启动！

远程办公条件下，DevOps 如何加快研发交付

持续交付体系在高德的实践历程

“DevOps时代”公众号诚邀广大技术人员投稿。投稿邮箱：jiachen@greatops.net 或 添加联系人微信：135 2116 9787(同微信)。点击，立即报名 GOPS 2020 · 深圳站你点的每个赞，我都认真当成了喜欢

“DevOps时代”公众号诚邀广大技术人员投稿。

投稿邮箱：jiachen@greatops.net 或 添加联系人微信：135 2116 9787(同微信)。