從CI/CD過程開始，包含所有階段並負責創建自動化和無縫的軟件交付的一系列步驟稱爲CI/CD管道工作流。使用CI/CD管道，軟件發佈工件可以從代碼提交階段到測試、構建、部署和生產階段在管道中移動和前進。這個概念非常強大，因爲一旦指定了一個管道，它的一部分或全部就可以實現自動化，從而加快流程並減少錯誤。換句話說，CI/CD管道使企業更容易一天自動多次交付軟件。
DevOps工程師經常會因爲CI/CD中各個階段的自動化而與CI/CD管道混淆。雖然不同的工具可以使CI/CD中的各個複雜階段實現自動化，但由於人工干預，CI/CD的整個軟件供應鏈仍然可能被打破。那麼，就首先了解CI/CD過程中的各個階段，以及CI/CD管道爲什麼對於組織快速、大規模地交付代碼至關重要。
CI/CD階段：瞭解人員、過程和技術
企業應用程序開發團隊通常由開發人員、測試人員/QA工程師、運營工程師和SRE（站點可靠性工程師）或IT運營團隊組成。他們緊密合作，將高質量的軟件交付給客戶。CI/CD是兩個獨立過程的組合:持續集成和持續部署。下面列出了其中的主要步驟。
CI持續集成
持續集成(CI)是構建軟件並完成初始測試的過程。持續部署(CD)是將代碼與基礎設施結合起來的過程，確保完成所有測試並遵循策略，然後將代碼部署到預期的環境中。當然，許多公司都有自己的流程，但主要步驟如下。
CI：代碼提交
人員：開發人員和工程師、數據庫管理員（DBA）、基礎架構團隊
技術：GitHub、Gitlab、BitBucket
過程：代碼提交階段也稱爲版本控制。提交是將開發人員編寫的最新更改發送到存儲庫的操作。開發人員編寫的代碼的每個版本都被無限期地存儲。在與合作者討論和審查變更之後，開發人員將編寫代碼，並在軟件需求、功能增強、bug修復或變更請求完成後提交。管理編輯和提交變更的存儲庫被稱爲源代碼管理（SCM工具）。在開發人員提交代碼（代碼推送請求）後，代碼更改被合併到存儲在中央存儲庫（如GitHub）中的基本代碼分支中。
CI：靜態代碼分析
人員：開發人員和工程師、數據庫管理員（DBA）、基礎設施團隊、測試人員
技術：GitHub、Gitlab、BitBucket
過程：一旦開發人員編寫了代碼並將其推送到存儲庫，系統就會自動觸發，開始下一個代碼分析過程。想象一下這樣一個步驟：提交的代碼直接進行構建，但在構建或部署過程中失敗了。就資源利用率而言，無論是機器還是人力，這都是一個緩慢而昂貴的過程。必須檢查代碼的靜態策略。SAST（Static Application Security Test）：SAST是一種白盒測試方法，使用SonarQube、Veracode、Appscan等SAST工具從內部檢查代碼，以發現軟件缺陷、漏洞和弱點（如SQL注入等）。這是一個快速檢查過程，檢查代碼是否有語法錯誤。雖然此階段缺少檢查運行時錯誤的功能，但這將在稍後的階段執行。
將附加的策略檢查放到自動化管道中可以顯著減少稍後在該過程中發現的錯誤數。
CI：build
人員：開發人員和工程師
技術：Jenkins,、Bamboo CI、Circle CI、Travis CI、Maven、Azure DevOps
過程：持續集成流程的目標是接受常規的代碼提交，並持續構建二進制工件。持續集成過程通過檢查添加的新模塊是否與現有模塊配合良好，有助於更快地發現bug。這有助於減少驗證新代碼更改的時間。構建工具有助於編譯和創建可執行文件或包（.exe、。dll， .jar等）取決於用於編寫源代碼的編程語言。在構建過程中，還會生成SQL腳本，然後與基礎設施配置文件一起測試。簡而言之，構建階段是編譯應用程序的階段。構建過程的其他子活動包括工件存儲、構建驗證和單元測試。
CI：測試階段
人員：測試人員和QA工程師
技術：Selenium、Appium、 Jmeter、SOAP UI、Tarantula
過程：發佈一個構建過程一系列自動化測試來驗證代碼的準確性。這一階段有助於防止錯誤到達產品。根據構建的大小，此檢查可以持續數秒到數小時。對於由多個團隊提交和構建代碼的大型組織，這些檢查將在並行環境中運行，以節省寶貴的時間並儘早將Bug通知給開發人員。
這些自動化測試是由測試人員（或者稱爲QA工程師）建立的，他們已經根據用戶故事建立了測試用例和場景。他們進行迴歸分析，壓力測試，以檢查與預期產出的偏差。測試中涉及的活動有健全性測試、集成測試和壓力測試。這是一個非常先進的測試水平。在這裏會發現開發代碼的開發人員可能不知道的問題。
集成測試：
集成測試是使用Cucumber、Selenium等工具來執行的，其中各個應用程序模塊作爲一個組進行組合和測試，同時評估是否符合指定的功能需求。在集成測試之後，需要有人批准將該組中的更新集移動到下一階段，這通常是性能測試。這個驗證過程可能很麻煩，但它是整個過程的重要組成部分。覈查過程中出現了一些新的解決辦法。
負載和壓力測試：
負載平衡和壓力測試也使用自動化測試工具（如Selenium、JMeter等）來執行，以檢查應用程序在高流量環境下是否穩定和性能良好。此測試通常不會在每個更新上運行，因爲完整的壓力測試是長期運行的。在發佈主要的新功能時，將對多個更新進行分組，並完成完整的性能測試。在單個更新被轉移到下一個階段的情況下，管道可能包括金絲雀測試作爲替代方案。
持續部署：bake和部署
人員：基礎設施工程師、現場可靠性工程師（SRE）、運維工程師
技術：Spinnaker、Argo CD、Tekton CD
過程：測試階段完成後，清除了標準的代碼就可以部署到服務器中，在那裏它們將與主應用程序集成。在部署到生產環境之前，它們將被部署到產品團隊內部使用的測試/暫存或beta環境中。在將構建移動到這些環境之前，構建必須經過兩個子階段Bake和Deploy。這兩個階段都是Spinnaker固有的。
CD：Bake
Bake是指從源代碼中創建一個不可變的映像實例，該實例在生產環境中具有當前配置。這些配置可能是數據庫更改和其他基礎設施更新之類的內容。Spinnaker可以觸發Jenkins來執行這個任務，有些組織更喜歡使用Packer。
CD：部署
Spinnaker將自動將烘焙的映像傳遞到部署階段。這是將服務器組設置爲部署到集羣的位置。與上述測試過程類似，在部署階段執行功能相同的過程。部署首先轉移到測試、階段，最後轉移到生產環境，然後進行批准和檢查。整個過程由Spinnaker之類的工具處理。
CD：驗證
這也是團隊優化整個CI/CD流程的關鍵所在。因爲現在已經進行了很多測試，所以失敗應該很少。但此時的任何故障都需要儘快解決，以便將對最終客戶的影響降到最低。團隊也應該考慮自動化這部分流程。
部署到生產環境是使用部署策略（如藍綠部署、金絲雀分析、滾動更新等）執行的。在部署階段，將監視正在運行的應用程序，以驗證當前部署是否正確或是否需要回滾。
CD：監控
人員：SRE，運維團隊
技術：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli
過程：要使一個軟件發行版具有故障安全性和健壯性，在生產環境中跟蹤發行版的運行狀況是至關重要的。應用程序監控工具將跟蹤CPU利用率和發佈延遲等性能指標。日誌分析器將掃描底層中間件和操作系統產生的日誌流，以識別行爲並跟蹤問題的來源。在生產過程中出現任何問題時，都會通知相關人員，以確保生產環境的安全性和可靠性。此外，監視階段幫助企業收集有關新軟件更改如何爲收入做出貢獻的信息，並幫助基礎架構團隊跟蹤系統行爲趨勢和進行容量規劃。
持續部署：反饋和協作工具
人員：SRE、Ops和維護團隊
技術：禪道、ServiceNow、Slack、Email、Hipchat
DevOps團隊的目標是更迅速、持續地發佈，然後不斷減少錯誤和性能問題。這是通過slack或電子郵件頻繁地向開發人員和項目經理反饋新版本的質量和性能，並在ITSM工具中及時提高票價來實現的。通常，反饋系統是整個軟件交付過程的一部分；因此交付過程中的任何更改都會頻繁地記錄到系統中，以便交付團隊可以對其採取行動。
企業必須評估一個整體的持續交付解決方案，它可以自動化或促進上述階段的自動化。