測試私有方法重構_一個全棧工程師重構之路：中小公司 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同理，不同分支處理不同客戶項目。