你以為搞個流水線每天跑，團隊就在使用CI/CD實踐了？
在實踐中，很多團隊對于DevOps 流水線沒有很透徹的理解，要不就創建一大堆流水線，要不就一個流水線通吃。實際上，流水線的設計和寫代碼一樣，需要基于“業務場景”進行一定的設計編排，特別是很多通過“開源工具”搭建的流水線，更需要如此（商業的一體化平臺大部分已經把設計思想融入自己產品里了）。
- 流水線的設計與分支策略有關
- 流水線的設計與研發活動有關
清晰的代碼結構，標準的環境配置，原子化的流水線任務編排，再加上團隊的協作紀律，和持續優化的動作，才是真正的踐行CI/CD實踐
流水線設計原則
1. 確定好變量
- 哪些是構建/部署需要變化的，比如構建參數，代碼地址，分支名稱，安裝版本，部署機器IP等，控制變化的，保證任務的可復制性，不要寫很多hardcode進去
2. 流水線變量/命名的規范化
- 標準化的命名，有助于快速復制；有意義的流水線命名，有助于團隊新成員快速了解
3. 一次構建，多次部署
- 一次構建，多次部署（多套環境配置+多套構建版本標簽）；杜絕相同代碼重復打包
- 相似技術棧/產品形態具備共性，通過以上原則可以抽取復用腳本，良好的設計有助于后續的可維護性！
4. 步驟標準化/原子化
- 比如docker build/push, helm build/deploy, Maven構建等動作標準化，避免重復性寫各種腳本邏輯
- 根據業務場景組裝，例如. 提測場景，每日構建場景，回歸測試場景
5. 快速失敗
從零開始設計流水線
流水線分步驟實施, 從 “點” 到 “線” 結合業務需要串起來，適合自己團隊協作開發節奏的流水線才是最好的。
- 對價值流進行建模并創建簡單的可工作流程
- 將 構建 和 部署 流程自動化
- 將 單元測試和 代碼分析 自動化
- 將 驗收測試 自動化
- 將 發布 自動化
流水線的分層
由于產品本身的形態不同，負責研發的團隊人員組成不同，代碼的版本管理分支策略不同，使用的部署流水線形式也會各不相同，所以基于實際業務場景設計流水線是團隊工程實踐成熟的重要標志。
1. 提交構建流水線（個人級）
適用場景：每名研發工程師都創建了自己專屬的流水線（一般對應個人的開發分支），用于個人在未推送代碼到團隊倉庫之前的快速質量反饋。
注意：個人流水線并不會部署到 團隊共同擁有的環境中，而是僅覆蓋個人開發環節。如圖所示，虛線步驟非必選
2. 集成驗收流水線（團隊級）
適用場景：每個團隊都根據代碼倉庫（master/release/trunk）分支，創建產品專屬的流水線，部署到 團隊共同擁有的環境中e.g. dev）。
注意：如圖所示，虛線步驟非必選，根據情況可通過 啟動參數true/flase 跳過執行，自動化測試僅限于保證基本功能的用例。
3. 部署測試流水線（團隊級）
適用場景：每個團隊的測試工程師都需要專門針對提測版本的自動化部署/測試流水線，部署到團隊共同擁有的環境中（e.g. test）.
注意：如圖所示，該條流水線的起點不是代碼，而是提測的特定版本安裝包；虛線步驟非必選，根據情況可通過 啟動參數true/flase 跳過執行 或 裁剪。
4. 多組件集成流水線
適用場景：如果一個產品由多個組件構建而成，每個組件均有獨自的代碼倉庫，并且每個組件由一個單獨的團隊負責開發與維護，那么，整個產品 的部署流水線的設計通常如下圖所示。 集成部署流水線的集成打包階段將自動從企業軟件包庫中獲取每個組件最近成功的軟件包，對其進行產品集成打包
5. 單功能流水線
適用場景：適用于和代碼變更無關的場景，不存在上面步驟復雜的編排 (也可通過上述流水線的 啟動參數進行條件控制，跳過一些步驟)
6. 全功能（持續交付）流水線
適用場景：需求、代碼構建、測試、部署環境內嵌自動化能力，每次提交都觸發完整流水線，中間通過人工審批層次卡點，從dev環境,test環境,stage環境一直到 prod環境。 常適用于快速發布的 PASS/SASS服務，對團隊各項能力和流程制度要求較高，支持快速發布（策略）和快速回滾（策略）
流水線運轉全景圖
團隊研發工程師每人每天都會提交一次。因此，流水線每天都會啟動多次。當然并不是每次提交的變更都會走到最后的“上傳發布” 。 也不是每次提交都會走到UAT 部署，因為開發人員并不是完成一個功能需求后才提交代碼，而是只要做完一個開發任務，就可以提交。每個功能可能由 多個開發任務組成，研發工程師需要確保即使提交了功能尚未開發完成的代碼，也不會影響已開發完成的那些功能。
制品經過一個個質量卡點，經歷各種門禁驗證，最終交付給客戶 可以工作的軟件
浙公網安備 33010602011771號