我是如何重構整個研發項目，促進自動化運維DevOps的落地？

爲了這篇文章，我先後寫了將近十篇文章鋪墊，纔將這篇總體重構思想引出。

背景

先說下背景，咱們是一家小公司，雖然打着作產品的旗幟，可是每一個客戶都有大量的個性化功能，這裏指各個客戶的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命令嗎？快試試Sourcetree吧》

開發流程以下：

開發人員只須要本地調試後，提交代碼到git庫的某個項目分支上，由Jenkins自動編譯，關於Jenkins自動編譯全端項目可參照我另一篇文章
某小型公司持續集成工具jenkins實踐（JAVA WEB、Android、IOS、html）
若是編譯錯誤會經過郵件反饋到影響代碼的開發人員郵箱中，另外測試人員一鍵部署後，測試出問題，也能夠經過jira提單給開發人員。開發人員收到後，繼續提交代碼，再也不像咱們以前，必須通知開發人員，開發人員本地打包，這樣沒法跟蹤項目代碼。

補充：
由於咱們項目比較多，人爲維護版本號會費時費力，我決定一期採用Jenkins自動填入版本號到項目中，並在文件名中體現，因此，項目編譯出的包多是1.war、2.war、3.war，咱們內部將其（一、二、3）做爲版本號，固然war包內部我也寫入了版本號。
其次，咱們剔除了大量含狀態的代碼，使得每一個war在測試環境和生產環境自動加載不一樣配置來運行，由於無狀態，因此war包、h5包在測試環境和生產環境都是一套代碼。這裏咱們花了幾周時間完成抽取無狀態代碼。

一鍵部署：
咱們作了一套管理平臺，可升級tomcat中間件下的各個war和h5，相關介紹見我另一篇文章
java web項目war包自動升級部署方案
能夠看看咱們如今的效果：

主要功能以下：

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來解決，並二次開發了一些需求。
詳細可看我另一篇文章
Docker的web端管理平臺對比（DockerUI 、Shipyard、Portainer、Daocloud）
這裏的管理都不須要linux機器的密碼，經過tls證書進行控制，而Windows機器將廢棄不用。

該方案優勢：

1. 在docker下，全部客戶生產環境相同。
2. 易於備份、遷移、恢復。
3. 可建高可用環境，發包時採用灰度發包，藍綠部署不中斷服務。
4. 可支持彈性伸縮設計，支持擴展。
5. 支持負載均衡，域名轉發，意外切換容器等。
6. 有利於轉型微服務架構。
7. 快速搭建環境

而創建docker集羣須要咱們自動化完成，這裏我採用了Ansible工具來實施，咱們可經過指令分發，指令獲取全部機器某個包的版本，執行不一樣的代碼。
詳細參照我另一篇文章：
自動化運維工具ansible的實踐

而後經過image鏡像對客戶進行統一部署容器，這裏咱們創建了私服。

私服篇

這裏我創建了各類倉庫，方便java開發，我創建了一個私有倉庫，一個maven官方代理倉庫，一個阿里雲代理倉庫；
docker上我爲了方便開發打包其餘環境，我建立了docker私有倉庫；
還有一些爲了解決統一管理linux服務器而建立npm倉庫；
以及安卓所要使用的gradle私有倉庫；
將來，我可能還會建立更多倉庫，能支持的倉庫列表都在下面：

私服

詳細可參照我另一篇文章
利用nexus構建maven、docker、npm、gradle私服倉庫

大數據篇

大數據一直以來是不少公司核心產品，對於小公司，如何低成本實施呢，我研究了一套強大的大數據框架，並對其作了部分的二次開發。
詳細可參照另一篇文章
juejin.im/post/596702…
放心吧，只要你用了這個框架，必定能夠輕鬆解決各類大數據圖表問題。

接口篇

我全面統一採用restful風格api開發接口，接口文檔自動生成，這裏涉及幾篇文章，暫時還沒來得及寫，後續補上。

規範篇

我還制定了一些規範和約定，好比內部開發協做等約定，暫時還沒寫完，後期我也會補上。

文化篇

以前，咱們開發需求徹底依靠項目經理分配，如今我安排不斷重構項目，帶來了不少新的流程，這裏徵得領導贊成，安排每週或每2周分別對各部門，培訓後分配帳號，實施。這個涉及公司內部業務，不便詳說，敬請諒解。

DevOps的落地

DevOps這個詞，是我上次在上海CNUTCon全球運維技術大會2017會上所知，我才知道大部分公司都在作自動化運維，縮減運維工做。
關於這方面，我也寫了2篇文章，可參照
[Day 1]上海CNUTCon全球運維技術大會2017實錄
[Day 2]上海CNUTCon全球運維技術大會2017實錄
在文章中，我融入了很多本身的想法。
固然，適合咱們公司DevOps的落地方案已經實施一大半了，剩下的我還在努力設計藍圖中。之後必定會和你們分享。

後續

我寫了幾個月各方面的文章，大部分讀者可能覺得我是胡寫一通。今天，終於把他們匯聚到一塊兒，說實話，心情仍是蠻激動的。

我認可我全部的重構對於不少大公司都是提不上臺面的，但對於咱們小公司，不少東西造成體系，說實話，真的很難。還有些內容，我不方便說，或者是忘記了說。事實上，咱們作的遠比文章裏的內容要多得多。
還有，部分文章多是幾個月前寫的，邏輯上和流程上，咱們都已經作了不少優化和調整，可是主體思想都沒有變，不影響閱讀。

其次，我申明，本文中全部介紹，絕對不是最好的解決方案，不少方案是我對公司進行分析後定下的，毫不是每一個小公司都適合。但我以爲本文必定能給你帶來很多的靈感。

最後，本人能力有限，開發圈子也比較小，不免有考慮不周的地方，若是您有任何高見，歡迎告知，小生在此謝過你們。