本文將引導您探索創建可加速部署的管道的實際步驟。

持續集成/持續交付 (CI/CD) 流水線已成為發布軟件不可或缺的一部分，但它們的用途往往會被誤解。在許多情況下，CI/CD 管道被視為解決發布問題的解毒劑，但實際上，它們的有效性取決于它們所代表的底層發布過程。在本文中，我們將了解創建有效 CI/CD 管道的幾個簡單步驟，包括如何捕獲和簡化現有發布流程，以及如何將該流程轉換為精益管道。

捕獲發布過程

CI/CD 管道并不是解決我們所有發布瓶頸的靈丹妙藥，如果底層發布過程出現問題，它也只能提供最小的改進。對于軟件，發布過程是團隊用來將代碼從源代碼文件中獲取到可以交付給客戶的打包產品的一組步驟。該過程將反映每個產品和創建產品的團隊的 業務需求。

雖然發布過程的細節會有所不同——有些可能需要某些安全檢查，而另一些可能需要第三方的批準——但幾乎所有軟件發布過程都有一個共同的目的：

• 將源代碼構建并打包成一組工件
• 通過各種級別的審查來測試工件，包括單元、集成和端到端 (E2E) 測試
• 從最終用戶的角度測試產品的關鍵工作流程
• 將工件部署到類似生產的環境中以對部署進行冒煙測試

每個向客戶交付產品的團隊都有一些發布流程。這個過程可以從“通過電子郵件將工件發送給吉姆以便他可以測試它們”到非常嚴格和正式的過程，團隊或經理必須在過程中的每個步驟完成時簽字。

寫在紙上

盡管存在這種差異，但開發有效的 CI/CD 管道的第一個也是最關鍵的步驟是捕獲發布過程。最簡單的方法是繪制一組框來捕獲發布過程中的步驟，并繪制從一個步驟到另一個步驟的箭頭以顯示一個步驟的完成如何啟動另一個步驟的開始。這幅畫不必過于正式；它可以在一張紙上完成，只要捕獲當前實踐的過程即可。圖 1 說明了一個簡單的發布過程，該過程對許多產品都很常見：

圖 1：基本發布流程 - 捕獲當前發布流程的步驟是創建管道的第一步

說同一種語言

一旦捕獲了當前的發布過程，下一步就是使該過程正式化。在談到發布過程以及最終的 CI/CD 管道時，使用通用的本地語言或領域語言非常重要。

對于管道，基本詞典是：

• Step – 發布過程中的單個操作，例如Build、Unit Tests或Staging（即框）。
• 階段——發布過程中的一個階段，包含一個或多個步驟。通常，階段可以被認為是管道中的順序列。例如，Build包含在第一階段，Unit Test包含在第二階段，User Tests和Staging包含在第五階段。當一個階段中只有一個步驟時，術語步驟和階段通常作為同義詞使用。
• 管道——一組有序的步驟。
• 觸發器– 啟動管道單次執行的事件，例如簽入或提交。
• 門- 必須在所有后續步驟開始之前完成的手動步驟。例如，在部署產品之前，團隊或經理可能需要在完成測試后簽字。

CI/CD 管道只是正式發布流程的自動化實現。因此，如果我們希望創建一個有效的 CI/CD 流水線，那么首先優化我們的發布流程是必不可少的。

優化發布流程

由于我們的 CI/CD 管道反映了我們的發布流程，因此創建有效管道的最佳方法之一是在從中派生管道之前優化發布流程本身。我們可以對發布流程進行三個關鍵優化，從而為有效的管道帶來好處：

1. 簡化流程——我們應該盡量減少任何會減慢發布流程的瓶頸或人為步驟。

• 刪除任何不必要的步驟。
• 在滿足業務需求的同時最大限度地減少步驟數。
• 簡化任何復雜的步驟。
• 刪除或分發需要單一聯系點的步驟。
• 加速長時間運行的步驟并將它們與其他步驟并行運行。

2. 自動化一切——理想的發布過程沒有手動步驟。雖然這并不總是可能的，但我們應該自動化每一個可能的步驟。

• 考慮JUnit、Cucumber、Selenium、Docker和Kubernetes等工具和框架。
• 捕獲在腳本中運行每個步驟的過程——即，運行構建應該和執行build.sh. 這確保沒有神奇的命令，并允許我們在故障排除或復制發布過程時按需運行每個步驟。
• 創建可以在發布過程運行的任何地方運行的可移植腳本。不要使用僅適用于特定、特殊用途環境的命令。
• 對腳本進行版本控制，最好與源代碼位于同一存儲庫中。

3. 縮短發布周期——我們應該盡可能頻繁地發布我們的產品。即使最終可交付成果沒有交付給客戶或用戶（例如，我們每天都在構建產品，但每周只向客戶發布一次產品），我們也應該經常運行我們的發布流程。如果我們目前每天執行一次發布過程，我們應該努力在每次提交時完成它。

優化發布流程可確保我們在精簡高效的基礎上構建 CI/CD 管道。發布過程中的任何膨脹都會反映在我們的管道中。優化我們的發布流程將是迭代的，并且需要不斷努力以確保我們在添加更多步驟以及現有步驟變得更大和更全面時保持精益發布流程。

構建管道

一旦我們有了優化的發布流程，我們就可以實施我們的管道。為了創建有效的 CI/CD 管道，我們應該遵循三個重要的建議：

1. 不要追隨時尚——有無數的噱頭和時尚在爭奪我們的注意力，但我們的職業責任是根據對我們的需求最有效的東西來選擇我們的工具和技術。普遍性和流行性并不能保證有效性。目前，CI/CD 管道工具的選項包括GitHub Actions、GitLab CI/CD和Jenkins。這不是一個完整的列表，但它確實提供了一個穩定的起點。
2. 保持簡單性——理想情況下，每個步驟都應該運行一個腳本，管道配置中沒有硬編碼命令。管道配置應該被認為是膠水并且應該包含盡可能少的邏輯。例如，.gitlab-ci.yml圖 1 中發布過程的理想 GitLab CI/CD 配置 ( ) 類似于： ?build: stage: building script: - /bin/bash build.shunit-tests: stage: unit-testing script: - /bin/bash run-unit-tests.shintegration-tests: stage: integration-testing script: - /bin/bash run-integration-tests.sh...deploy: stage: deployment script: - /bin/bash deploy.sh --env production:443 --key ${SOME_KEY}這個理想并不總是可能的，但這應該是我們努力的目標。
3. 收集反饋——我們的管道不僅應該產生工件，還應該產生報告。這些報告應包括：

• 顯示測試用例總數、通過和失敗的測試報告
• 衡量我們被測產品性能的報告
• 顯示管道執行時間的報告——整體和每個步驟
• 可追溯性報告顯示哪些提交落入構建以及哪些票證（例如 Jira 或 GitHub 票證）與構建相關聯

這種反饋使我們不僅可以優化我們的產品，還可以優化構建它的管道。

通過遵循這些提示，我們可以構建一個有效的管道來滿足我們的業務需求，并為我們的用戶和客戶提供最大的價值和最少的摩擦。

結論

CI/CD 管道并不是解決我們所有發布問題的靈丹妙藥。雖然它們是可以顯著改進我們軟件發布的重要工具，但它們的有效性取決于我們的底層發布流程。為了創建有效的管道，我們需要簡化我們的發布流程并保持警惕，以便我們的管道盡可能保持簡單和自動化。