使用一條 CI/CD 流水線管理所有的產品

當我加入 WorkSafeBC 負責雲端運維和工程流程優化的雲端運維團隊時，我和大家分享了我的夢想，那就是一個工具化的流水線，每一個產品都可以持續集成和持續交付。

根據 Lukas Klose 的說法， 流程 flow （在軟體工程的語境內）是「軟體系統以穩定和可預測的速度創造價值的狀態」。我認為這是最大的挑戰和機遇之一，特別是在複雜的新興解決方案領域。我力求通過一種持續、高效和優質的解決方案，提供一種持續交付模式，並且能夠構建正確的事物讓我們的用戶感到滿意。想辦法把我們的系統分解成更小的碎片，這些碎片本身是有價值的，使團隊能夠漸進式地交付價值。這需要業務和工程部門改變思維方式。

持續集成和持續交付的（CI/CD）流水線

CI/CD 流水線是一種 DevOps 實踐，用於更頻繁、一致、可靠的地交付代碼變更。它可以幫助敏捷開發團隊提高部署頻率，減少變更準備時間、變更失敗率和關鍵績效指標（KPI）的平均恢復時間，從而提高質量並且實現更快的交付。唯一的先決條件就是堅實的開發流程、對質量的心態和對需求從構想到廢棄的責任心，以及一個全面的流水線（如下圖所示）。


它簡化了工程流程和產品，以穩定基礎架構環境；優化工作流程；並創建一致的、可重複的、自動化的任務。正如 Dave Snowden 的 Cynefin Sensemaking 模型所說的那樣，這樣就允許我們將複雜不可解決的任務變成了複雜可解決的任務，降低了維護成本，提高了質量和可靠性。

精簡流程的一部分是將 浪費實踐類型 wasteful practice types Muri（過載）、Mura（變異）和 Muda（浪費）的浪費降低最低。

• Muri（過載）：避免過度工程化，避免與商業價值不相關的功能以及過多的文檔。
• Mura（變異）：改善審批和驗證流程（比如，安全簽批）；推動 左移提前 shift-left 策略以推行單元測試、安全漏洞掃描與代碼質量檢查；並改進風險評定。
• Muda（浪費）：避免技術債、錯誤或前期的詳細文檔等浪費。

看起來 80％ 的重點都集中在提供一種可以集成和協作的工程產品上，這些系統可以採用一個創意和計劃、開發、測試和監控你的解決方案。然而，一個成功的轉型和工程系統是由 5％ 的產品、15％ 的過程和 80％ 的開發人員組成的。

我們可以使用的產品有很多。比如，Azure DevOps 為持續集成（CI）、持續交付（CD）和可擴展性提供了豐富支持，並與 Stryker、SonarQube、WhiteSource、Jenkins 和 Octopus 等開源集成和商用成品（COTS）軟體即服務（SaaS）進行集成。對於工程師來說，關注產品總是一種誘惑，但請記住，它們只是我們旅程的 5%。


最大的挑戰是打破數十年的規則、規定和已經步入舒適區的流程：「我們一直都是這樣做的；為什麼需要改變呢？」

開發和運維人員之間的摩擦導致了各種支離破碎的、重複的、不間斷的集成和交付流水線。開發人員希望能訪問所有東西，以便持續迭代，讓用戶使用起來和持續地快速發布。運維人員希望將所有東西鎖起來，保護業務、用戶和品質。這些矛盾在不經意間導致了很難做到一種自動化的流程，進而導致發布周期晚於預期。

讓我們使用最近的一次白板討論中的片段來探索流水線。

想要支持流水線的變化是一項困難並且花費巨大的工作；版本和可追溯性的不一致使得這個問題變得更加複雜，因此不斷精簡開發流程和流水線是一項挑戰。


我主張一些原則使得每個產品都能使用通用流水線：

• 使一切可自動化的東西都自動化
• 一次構建
• 保持持續集成和持續交付
• 保持持續精簡和改進
• 保持一個構建的定義
• 保持一個發布流水線的定義
• 儘早、頻繁地掃描漏洞，並且儘快失敗
• 儘早、頻繁地進行測試，並且儘快失敗
• 保持已發布版本的可追蹤和監控

但是，如果我要打破這些，最重要的原則就是保持簡單。如果你不能說明流水線化的原因（是什麼、為什麼）和過程（如何），你或許是不了解自己的軟體過程的。我們大多數人想要的不是最好的、超現代的和具有革命意義的流水線 —— 我們僅僅是需要一個功能強大的、有價值的和能促進工程的流水線。首先需要解決的是那 80% —— 文化、人員和他們的心態。請你的 CI/CD 騎士們穿上閃亮的盔甲，在他們的盾牌上貼上 TLA（ 兩個/三個字母的縮寫 two/three-lettered acronym ）符號，加入到實踐和經驗工程的力量中來。

統一流水線

讓我們逐步完成我們的白板會議實踐。


每個應用使用一套構建定義來定義一個 CI/CD 流水線，用來觸發拉取請求的預合併驗證與持續集成的構建。生成一個帶有調試信息的發布的構建，並且將其上傳到 符號伺服器。這使開發人員可以在本地和遠程生產環境進行調試，而在不用考慮需要載入哪個構建和符號，符號伺服器為我們施展了這樣的魔法。


在構建過程中進行儘可能多的驗證（左移提前），這允許開發新特性的團隊可以儘快失敗，不斷的提高整體的產品質量，並在拉取請求中為代碼審核人員提供寶貴證據。你喜歡有大量提交的拉取請求嗎？還是一個帶有少數提交和提供了漏洞檢查、測試覆蓋率、代碼質量檢查和 Stryker 突變殘餘等支持的拉取請求？就我個人而言，我投後者的票。


不要使用構建轉換來生成多個特定環境的構建。通過一個構建實現發布時轉換、標記化和 XML/JSON 的值替換。換句話說，右移滯後具體環境的配置。


安全存儲發布配置數據，並且根據數據的信任度和敏感度，讓開發和運維都能使用。使用開源的密鑰管理工具、Azure 密鑰保險庫、AWS 密鑰管理服務或者其他產品，記住你的工具箱中有很多方便的工具。


使用用戶組而不是用戶，將審批人管理從跨多個流水線的多個階段移動到簡單的組成員。


創建一條流水線並且對賦予特定的交付階段的許可權，而不是重複流水線讓團隊進入他們感興趣的地方。


最後，但並非最不重要的是，擁抱拉取請求，以幫助提高對代碼倉庫的洞察力和透明度，增進整體質量、協作，並將預驗證構建發布到選定的環境，比如，開發環境。

這是整個白板更正式的視圖。


所以，你對 CI/CD 流水線有什麼想法和經驗？我的通過一條流水線來管理它們的這個夢想是空想嗎？

via: https://opensource.com/article/19/7/cicd-pipeline-rule-them-all

作者：Willy-Peter Schaub 選題：lujun9972 譯者：chunibyo-wly 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive