测试私有方法重构_一个全栈工程师重构之路：中小公司 DevOps 落地实践

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

背景

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

前言

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

先说说效果

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

Java 项目组

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

接口服务
后台服务
html5包
公共包服务

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

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

开发流程如下：

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

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

补充：

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

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

主要功能如下：

升级、显示当前版本
对war包有效期，真实性校验
开发人员将公共sql放入公共.sql里
各个客户定制化需求的sql放入各个客户.sql里

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

客户端组

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

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