你以為搞個流水線每天跑，團隊就在使用CI/CD實踐了？

在實踐中，很多團隊對於DevOps 流水線沒有很透徹的理解，要不就建立一大堆流水線，要不就一個流水線通吃。實際上，流水線的設計和寫程式碼一樣，需要基於「業務場景」進行一定的設計編排，特別是很多通過「開源工具」搭建的流水線，更需要如此（商業的一體化平臺大部分已經把設計思想融入自己產品裡了）。

• 流水線的設計與分支策略有關
• 流水線的設計與研發活動有關

清晰的程式碼結構，標準的環境設定，原子化的流水線任務編排，再加上團隊的共同作業紀律，和持續優化的動作，才是真正的踐行CI/CD實踐

流水線設計原則

1. 確定好變數

• 哪些是構建/部署需要變化的，比如構建引數，程式碼地址，分支名稱，安裝版本，部署機器IP等，控制變化的，保證任務的可複製性，不要寫很多hardcode進去

2. 流水線變數/命名的規範化

• 標準化的命名，有助於快速複製；有意義的流水線命名，有助於團隊新成員快速瞭解

3. 一次構建，多次部署

• 一次構建，多次部署（多套環境設定+多套構建版本標籤）；杜絕相同程式碼重複打包
• 相似技術棧/產品形態具備共性，通過以上原則可以抽取複用指令碼，良好的設計有助於後續的可維護性！

4. 步驟標準化/原子化

• 比如docker build/push, helm build/deploy, Maven構建等動作標準化，避免重複性寫各種指令碼邏輯
• 根據業務場景組裝，例如. 提測場景，每日構建場景，迴歸測試場景

5. 快速失敗

• 儘可能把不穩定的，耗時短的步驟 放在流水線的最前面，如果把一個穩定的步驟放在前面，並且耗時幾十分鐘，後面的某個步驟掛了，反饋週期就會變長
  

從零開始設計流水線

流水線分步驟實施, 從 「點」 到 「線」 結合業務需要串起來，適合自己團隊共同作業開發節奏的流水線才是最好的。

1. 對價值流進行建模並建立簡單的可工作流程
2. 將 構建 和 部署 流程自動化
3. 將 單元測試和 程式碼分析 自動化
4. 將 驗收測試 自動化
5. 將 釋出 自動化

流水線的分層

由於產品本身的形態不同，負責研發的團隊人員組成不同，程式碼的版本管理分支策略不同，使用的部署流水線形式也會各不相同，所以基於實際業務場景設計流水線是團隊工程實踐成熟的重要標誌。