流水線設計和編排
云計算團隊 2020-03-16
對于DevOps流水線，主要是由各類任務串聯起來，而對于任務本身又分為兩張類型，一種是自動化任務，一種是人工執行任務。具體如下：
1. 自動化任務：包括了代碼靜態檢查，構建，打包，部署，單元測試，環境遷移，自定義腳本運行等。
2. 人工任務：人工任務主要包括了檢查審核，打標簽基線，組件包制作等類似工作。
而通常我們看到的流水線基本都由上述兩類任務組合編排而成，一個流水線可以是完全自動化執行，也可以中間加入了人工干預節點，在人工干預處理后再繼續朝下執行。比如流水線中到了測試部署完成后，可以到測試環境人工驗證環節，只有人工驗證通過再流轉到遷移發布到生產環境動作任務。
DevOps流水線實際上和我們原來經常談到的持續集成最佳實踐是相當類似的，較大的一個差異點就在于引入了容器化技術來實現自動化部署和應用托管。至于在DevOps實踐中，是否必須馬上將項目切換到微服務架構框架模式，反而不是必須得。
在整個DevOps流水線中，我們實際上強調個一個關鍵點在于一套Docker鏡像文件+多套環境配置+多套構建版本標簽做法。以確保我們最終構建和測試通過的版本就是我們部署到生產環境的版本。構建操作只有一次，而后面到測試環境，到UAT環境，到生產環境，都屬于是鏡像的環境遷移和部署。而不涉及到需要再次重新打包的問題。這個是持續集成，也是DevOps的基本要求。
對流水線編排本身的靈活性進一步思考：
構建操作：構建我們通常采用Maven進行自動化構建，構建完成輸出一個或多個Jar包或War包。注意常規方式下構建完執行進行部署操作，部署操作一般就是將構建的結果拷貝到我們的測試環境服務器，同時對初始化腳本進行啟動等。而在DevOps下，該操作會變成兩個操作，即一個打包，一個部署。打包是將構建完成的內容制作為鏡像，部署是將鏡像部署到具體的資源池和指定集群。
打包操作：實際上即基于構建完成的部署包來生成鏡像。該操作一般首先基于一個基礎鏡像文件基礎上進行，在基礎鏡像文件上拷貝和寫入具體的部署包文件，同時在啟動相應的初始化腳本。
那么首先要考慮構建操作和打包操作如何松耦合開，打包操作簡單來就是就是一個鏡像制作，需要的是構建操作產生的輸出。我們可以對其輸出和需要拷貝的內容在構建的時候進行約定。而打包任務則是一個標準化的鏡像制作任務，我們需要考慮的僅僅是基于：
1) 基于哪個基礎鏡像
2) 中間件容器默認目錄設置
3) 初始化啟動命令
即在實際的打包任務設計的時候，我們不會指定具體的部署包和部署文件，這個完全由編排的時候由上游輸入。
部署操作：部署操作相當更加簡單，重點就是將鏡像部署到哪個資源池，哪個集群節點，初始化的節點配置等。具體部署哪個鏡像不要指定，而是由上游任務節點輸入。
■ 任務節點間松耦合設計的意義
這種松耦合設計才能夠使流水線編排更加靈活。比如我們在進行了構建打包后，我們希望同時將打包內容部署到開發環境和測試環境。那么則是打包動作完成后需要對接兩個應用部署任務。這兩個部署任務都依托上面的打包結果進行自動化部署，可以并行進行。
對于測試環境部署完成后，我們需要進行測試人員手工驗證測試，如果測試通過，我們打標簽后希望能夠直接發布到UAT環境。而這種操作我們也希望通過一個流水線來設計和完成。這樣我們更加容易在持續集成看板上看到整個版本構建和遷移的完整過程。如果這是在一個大流水線里面，那么對于UAT環境部署任務就需要一直去追溯流水線上的最近的一個打包任務節點，同時取該任務節點產生的輸出來進行相應的環境部署操作。
在談DevOps的時候，一個重點就是和QAQC的協同，因此在流水線編排的時候一定要考慮各類測試節點，包括靜態代碼檢查，自動化的單元測試，人工的測試驗證。同時最好基于持續集成實踐，能夠將測試過程和整個自動化構建過程緊密結合起來。
簡單來說，測試人員發現build1.0.0001版本4個bug并提交，那么在下次自動化構建完成并單元測試通過后，測試人員能夠很清楚的看到哪些Bug已經修改并可以在新構建的版本進行驗證。只有這樣才能夠形成閉環，整個流水線作業才能夠更好的發揮協同作用。
遠行科技
遠行云商
