DevOps持續集成初體驗

持續集成

工做流和分支策略

master分支

master分支永遠指向線上的生產環境,且只有master分支能夠指向線上生產環境。

新特性分支

新特性的開發分支以版本號遞增命名(如v1.1.5)，項目結束後能夠刪除。多個新特性同時開發應該建立多個開發分支，分別以不一樣的版本號命名(如v1.1.4.1)

修復分支

修復分支用於從master切出來用於修復線上bug的緊急調試分支。分支命名使用 操做者(目前) 來命名。主要是爲了不在多個hotfix修復過程當中的調試衝突問題。

持續集成方案

爲了協調項目開發過程當中線上與新特新開發的衝突，以及緊急修復任務與未完成的新特性開發的衝突，採用了持續集成開發到測試到發佈的一體化方案。在整個DevOps中，環境治理是最重要的一方面。

要實現怎樣的環境治理？

在環境治理時，咱們定義了一下咱們須要怎樣的環境才能夠知足咱們的平常開發、測試和發佈的需求。

1. 首先，咱們須要一個穩定的生產環境，所謂穩定。

   1. 生產環境須要保證上線的代碼通過一個仿真環境的嚴格的驗證。
   2. 可以彈性伸縮，作到從容應對流量洪流。

2. 其次，咱們須要一個靈活的開發測試環境。

   1. 開發環境要作到隨意擴展，從而防止並行的開發項目相互踩踏。
   2. 開發環境要作到高度仿真。在解決線上bug時甚至須要作到線上環境的等價替換，直接切換成hotfix環境進行調試開發。
   3. 開發環境在隨意擴展時最好能夠跟調用域名解耦，防止出現擴展一個開發環境須要去從新解析一個域名的尷尬。
   4. 開發環境能夠隨時切成一個測試環境，從而應對多特性的測試，防止測試之間相互踩踏。

設計環境治理方案

爲了解決上面的提出的環境治理的需求，咱們對環境治理的方案作了以下設計？

多個特性能夠切出多個開發環境，線上bug也會切出一個開發環境，而後經過腳本切成hotfix環境進行調試。開發驗證後發佈到預發環境，通過發佈測試經過後發佈到生產環境。

客戶端在開發過程當中多個開發環境並存，能夠根據客戶端發佈需求隨意進行特性之間的合併，而後在合併後的開發環境中進行集成測試。對於不發佈或者延後發佈的特性，依舊留存在開發環境中，能夠同步開發。客戶端經過header中攜帶ack=特性值 來實現動態切換開發環境。

如何作到持續集成？

上面咱們設計好了環境治理的方案，那麼整個DevOps最核心的一環也就解決了，下面主要介紹這個治理方案的實現方法和思路。

如何管理Kubernetes？

集羣上咱們選擇使用Kubernets來構建整個服務體系。統一部署在Kubernets集羣上的各個環境，須要經過kubectl管理，點擊查看如何安裝和設置kubectl。

如何建立新的特性開發環境？

1. git切出新的分支，分支名建議使用特性版本號。
2. 項目跟目錄下執行 ./bin/add_service.sh 。 執行這個命令的前提是本地安裝並配置好kubectl
3. 將代碼提交到倉庫裏。
4. 進入飛流->流水線->開發測試環境，選擇對應的分支，指定你要建立的開發環境的特徵值。以下圖指定使用deploy分支部署一個特徵值爲dev(注意由於kubernets語法的緣由特徵值不支持「.」,建議使用「-」代替「.」。如：v1.1.4 => v1-1-4）的開發環境。
5. 如何使開發環境變成hotfix環境？

# 本地執行：切換開發環境和hotfix環境
kubectl exec $(kubectl get pods -o=name -l app=特徵值 |tail -n 1) sh ./change_env.sh 環境名

技術上如何實現？

至此，整個持續集成的設計方案和使用方法已經說完了，下面是實現這個設計和操做中使用到的幾個腳本的實現方案的說明，這裏作個記錄以便你們繼續改進。

多環境是如何隔離的？

經過Kubenetes自帶多容器能力實現環境隔離，每一個環境建立一個獨立多deployment和service。

客戶端如何動態映射？

經過kubenetes的ingress實現nginx的反向代理能力，經過配置分發規則，將不一樣特徵值的請求映射到不一樣的service上去。

add_service.sh的做用

由於咱們的DevOps是集成在飛流上的，所以目前沒有找到構建kubectl環境的方式，後續發現了能夠改進，因此須要本地提取當前集羣的ingress配置到本地ing文件。而後自動化構建腳本將自動識別是否應該在ingress文件上添加新的service配置。