1. 前言：
隨着容器技術的到來，我們傳統的軟件版本管理和發布方式也在慢慢地發生改變。它重新定義了軟件開發、測試、發布和部署的流程，對版本管理的工作流程也有了更高的要求。我們交付的不再僅僅是代碼文件、版本、功能；而是整個系統的運行環境，以及內外部用戶在不同階段進行部署和使用時的體驗。
本文介紹了PICT項目以此為目標，在版本管理和發布方面所做的一些努力和嘗試。
2. 關鍵詞：
微服務化組件、跨地域分布
3. 背景：
ZXNP-PICT項目是一個基於容器技術，采用微服務框架實現的智能ICT融合的PaaS系統；它是由許多微服務化的組件項目組成的，這些組件項目團隊分布在上海、成都、西安、南京等地。
PICT項目使用的是自己開發維護的軟件倉庫，對應不同的階段，邏輯上可以分成臨時庫、可用庫、發布庫等三種不同的倉庫。
3.1. 軟件倉庫流程：
1. 組件團隊CI測試通過的組件版本會推送到 臨時庫；
2. 整系統CI從臨時庫取各組件最新版本，測試通過后推送到 可用庫；
3. 交付發布
3.1 經過聯調、版本驗證之后，確定版本組件清單，對內發布；
3.2 交付對內測試，項目、質量審評會通過，將組件清單里的版本從 可用庫 同步到 發布庫，對外發布；（如果規划對外發布）
3.2. 需要考慮的問題：
· 保證各組件版本對應代碼的可追溯性
· 開發人員能夠清楚了解組件版本在軟件倉庫的狀態信息
· 軟件倉庫的遠程化
· 避免軟件倉庫出現集中爆發式訪問導致出現性能負荷問題
· 軟件倉庫的容災備份
· 各地用戶能快速部署所需的版本
· 軟件倉庫的權限控制
4. 解決問題
· 微服務化組件在 gerrit.zte.com.cn 庫中分別屬於各自獨立的工程。在PaaS版本構建發布時，如果照搬老經驗對代碼庫打標簽，明顯是不必要、不合適的。因為多組件之間的版本號並不統一，某些組件可能一個版本對應多個PaaS項目版本；某些組件可能是非PaaS項目下的，用的是自己項目的版本號。微服務框架使得產品的靈活性、自由度比以前要大得多。結合項目運作中遇到的問題，現已對推送組件的版本號做了一定的規范要求，這樣通過組件版本號就能追溯到具體代碼。
每次推送組件的版本號要求都是唯一的，相同版本號上傳會被倉庫拒絕。
根據組件的內容，版本號有以下幾種情況：
-
組件內只含開源軟件；
正式版本號 補丁版本號 開源版本號 開源版本號 2.2.5 3.0.7 每次推送，開源版本號要有變化
-
組件內既有開源軟件，也有PaaS項目文件；
正式版本號 補丁版本號 開源版本號.UniqueID 開源版本號.UniqueID 2.2.5.228093 2.2.5.cc759a8 注：UniqueID為gerrit changeid或七位短格式git commit id，保證在開源版本號內唯一，源碼可追溯。
每次推送，如果開源軟件有變更，則變化開源版本號；如果PaaS項目文件有變更，則變化UniqueID；如果兩者都有變更，則同時變化開源版本號、UniqueID。
-
組件內包含開源軟件，但是開源軟件里含有PaaS開發內容；
組件內為PaaS項目版本；正式版本號 補丁版本號 PaaS項目大版本號.UniqueID PaaS項目大版本號.pxx.UniqueID v1.16.20.03.228093 v1.16.20.03.p01.cc759a8 注：pxx中的p代表patch，xx為01-99數字，每對外發布一次版本，xx增加1；
UniqueID為gerrit changeid或七位短格式git commit id，保證在PaaS項目版本號內唯一，源碼可追溯。
每次推送，都需變化UniqueID；如果切換到了下個版本迭代，則同時變化PaaS項目大版本號、UniqueID 或者 PaaS項目大版本號、pxx、UniqueID。
-
組件為其他項目版本
正式版本號 補丁版本號 其他項目版本號 其他項目版本號 v5.10.20.b4.02.16922 v5.10.20.b4.03.24902 每次推送，版本號要有變化
· 在某些特定場景下開發人員需要了解組件版本在軟件倉庫的狀態信息，需要提供統一接口進行查詢
| curl http://10.62.40.90/shell/tempzart_upload_history -s|sh #查詢臨時庫組件版本上傳歷史記錄和狀態 curl http://10.62.40.90/shell/tempzart_uploadok_history -s|sh #查詢臨時庫組件版本成功上傳歷史記錄 curl http://10.62.40.90/shell/tempzart_getnew -s|sh #查詢master分支上最新組件版本清單 |
· 臨時庫@上海、可用庫@上海、發布庫@上海已在上海IT機房托管維護，設備的安全性、穩定性有了保障，達到了研發提效對遠程化的要求。
· 經過幾次的版本發布，可以發現一個規律。在每個版本剛發布的一兩天里，軟件倉庫的訪問量會有明顯的爆發增長。原先正常部署所需的時間被拉長了，而那些非上海環境的下載速度更是變得讓人無法接受，大家的工作效率受到嚴重影響。於是搭建各地鏡像倉庫就被提了出來，最早完成的是發布庫在各地鏡像倉庫的搭建，滿足了外部用戶的需求。之后針對開發團隊，搭建了可用庫在各地的鏡像庫。
在各地鏡像倉庫的系統上，只需增加計划任務定期執行“curl http://10.62.40.90/shell/validzart_sync -s|bash”命令，就可以輕松完成組件版本的同步。PaaS項目現在設定的同步周期是10分鍾，也就是說源庫的內容基本在10分鍾內可以同步到鏡像站點。每10分鍾內的同步組件數量一般都在個位數，對源庫的性能影響很小。后續如果繼續增加各地鏡像倉庫也很方便，相同操作流程即可搞定。
這些鏡像倉庫就像是git里的本地庫，每一個都是源庫的備份，鏡像站點越多，備份就越多。一旦源庫版本丟失，只需選擇任何一個鏡像庫，使用類似上面的同步腳本，即可把版本恢復到源庫里去。
· 通過部署跨地域、分布式鏡像倉庫提升了容災的能力，均衡了用戶訪問的性能負荷；但是要讓各地用戶能快速部署所需的版本，還需要提前做好一些准備工作。根據用戶使用情景來決定使用什么倉庫，用哪里的倉庫。在前面的”軟件倉庫流程圖示“我們可以看到基本有四個使用情景的部署，整系統ci測試、聯調&版本驗證、對內發布、對外發布。整系統ci測試對應臨時庫，聯調&版本驗證、對內發布對應可用庫，對外發布對應發布庫。install-pdm-cli.sh為PaaS預安裝腳本，配置對應的部署版本清單；同時為用戶選擇對應的、有效的、最快的倉庫，自動排除那些不可達的倉庫。這樣用戶只要選對情景參數，就能便捷的部署PaaS系統。
| bash install-pdm-cli.sh temp_srepo #供PaaS整系統ci或用戶自定義版本清單使用，pdm-cli取臨時庫最新，臨時倉庫 bash install-pdm-cli.sh ci_valid #使用master最新可用ci版本清單進行部署，自動選擇 可用倉庫 bash install-pdm-cli.sh valid_srepo #使用對內發布版本清單進行部署，自動選擇 可用倉庫 bash install-pdm-cli.sh #使用對外發布版本清單進行部署，自動選擇 發布倉庫 |
· 為了保證組件版本的安全性、准確性，各類倉庫對用戶操作有着不同的權限限制。目前臨時庫和可用庫對普通用戶只允許上傳（upload）組件版本的操作，其他包含“寫”性質的操作是被禁止的；在發布庫里，普通用戶只有”讀“性質操作的權限，其他都是禁止的。
5. 效果評價
采用上述措施之后，項目在多方面得到了提升、改善：
-
組件版本變得更清晰直觀，便於管理
通過組件的版本號就能大致知道組件的來源歸屬，開源、本項目、其他項目等；
已部署的PaaS系統，查看相關組件的版本號就能定位到具體代碼；
杜絕了以前開發人員用同一個版本號反復刪除推送組件的情況，保證了組件版本來源的唯一性。 -
制品庫變得更加強壯，實現了遠程化、自動化
鏡像倉庫的部署變得簡單，均采用了遠程化管理；
隨着各地鏡像庫數目的壯大，容災備份點也同步增加了；
異地倉庫的組件版本同步，通過調用遠程腳本，實現了統一維護，各地倉庫只需調用即可，實現自動化； -
支持多團隊異地協作聯調，實現節奏同步
存在依賴關系的異地項目團隊在提交各自組件版本入庫后，可及時在本地獲取到依賴對方的可用組件版本進行聯調； -
快速部署，倉庫共享
PaaS部署從原先的異地部署耗時半天，縮短到平均三十鍾左右就能完成一次；
各地倉庫組成了共享資源池，任何幾處同時出現問題都不會影響到用戶部署；
6. 適用對象
微服務化的多組件項目都會面臨類似的問題，相關項目可結合自身實際情況有選擇性的借鑒參考；如已使用PaaS的制品庫，可直接使用本文的同步方案。