本文將引導(dǎo)您探索創(chuàng)建可加速部署的管道的實際步驟。

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

捕獲發(fā)布過程

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

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

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

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

寫在紙上

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

圖 1：基本發(fā)布流程 - 捕獲當(dāng)前發(fā)布流程的步驟是創(chuàng)建管道的第一步

說同一種語言

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

對于管道，基本詞典是：

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

CI/CD 管道只是正式發(fā)布流程的自動化實現(xiàn)。因此，如果我們希望創(chuàng)建一個有效的 CI/CD 流水線，那么首先優(yōu)化我們的發(fā)布流程是必不可少的。

優(yōu)化發(fā)布流程

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

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

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

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

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

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

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

構(gòu)建管道

一旦我們有了優(yōu)化的發(fā)布流程，我們就可以實施我們的管道。為了創(chuàng)建有效的 CI/CD 管道，我們應(yīng)該遵循三個重要的建議：

1. 不要追隨時尚——有無數(shù)的噱頭和時尚在爭奪我們的注意力，但我們的職業(yè)責(zé)任是根據(jù)對我們的需求最有效的東西來選擇我們的工具和技術(shù)。普遍性和流行性并不能保證有效性。目前，CI/CD 管道工具的選項包括GitHub Actions、GitLab CI/CD和Jenkins。這不是一個完整的列表，但它確實提供了一個穩(wěn)定的起點。
2. 保持簡單性——理想情況下，每個步驟都應(yīng)該運(yùn)行一個腳本，管道配置中沒有硬編碼命令。管道配置應(yīng)該被認(rèn)為是膠水并且應(yīng)該包含盡可能少的邏輯。例如，.gitlab-ci.yml圖 1 中發(fā)布過程的理想 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}這個理想并不總是可能的，但這應(yīng)該是我們努力的目標(biāo)。
3. 收集反饋——我們的管道不僅應(yīng)該產(chǎn)生工件，還應(yīng)該產(chǎn)生報告。這些報告應(yīng)包括：

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

這種反饋使我們不僅可以優(yōu)化我們的產(chǎn)品，還可以優(yōu)化構(gòu)建它的管道。

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

結(jié)論

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