cd的元素及意思解釋 cd是什么

在軟件開發中經常會提到 持續集成(Continuous Integration)(CI)和 持續交付(Continuous Delivery)(CD)這幾個術語 。 但它們真正的意思是什么呢?
在談論軟件開發時 , 經常會提到 持續集成(Continuous Integration)(CI)和 持續交付(Continuous Delivery)(CD)這幾個術語 。 但它們真正的意思是什么呢?在本文中 , 我將解釋這些和相關術語背后的含義和意義 , 例如 持續測試(Continuous Testing)和 持續部署(Continuous Deployment) 。
概覽工廠里的裝配線以快速、自動化、可重復的方式從原材料生產出消費品 。 同樣 , 軟件交付管道以快速、自動化和可重復的方式從源代碼生成發布版本 。 如何完成這項工作的總體設計稱為“持續交付”(CD) 。 啟動裝配線的過程稱為“持續集成”(CI) 。 確保質量的過程稱為“持續測試” , 將最終產品提供給用戶的過程稱為“持續部署” 。 一些專家讓這一切簡單、順暢、高效地運行 , 這些人被稱為 運維開發(DevOps)踐行者 。
“持續”是什么意思?“持續”用于描述遵循我在此提到的許多不同流程實踐 。 這并不意味著“一直在運行” , 而是“隨時可運行” 。 在軟件開發領域 , 它還包括幾個核心概念/最佳實踐 。 這些是:

  • 頻繁發布:持續實踐背后的目標是能夠頻繁地交付高質量的軟件 。 此處的交付頻率是可變的 , 可由開發團隊或公司定義 。 對于某些產品 , 一季度、一個月、一周或一天交付一次可能已經足夠頻繁了 。 對于另一些來說 , 一天可能需要多次交付也是可行的 。 所謂持續也有“偶爾、按需”的方面 。 最終目標是相同的:在可重復、可靠的過程中為最終用戶提供高質量的軟件更新 。 通常 , 這可以通過很少甚至無需用戶的交互或掌握的知識來完成(想想設備更新) 。
  • 自動化流程:實現此頻率的關鍵是用自動化流程來處理軟件生產中的方方面面 。 這包括構建、測試、分析、版本控制 , 以及在某些情況下的部署 。
  • 可重復:如果我們使用的自動化流程在給定相同輸入的情況下始終具有相同的行為 , 則這個過程應該是可重復的 。 也就是說 , 如果我們把某個歷史版本的代碼作為輸入 , 我們應該得到對應相同的可交付產出 。 這也假設我們有相同版本的外部依賴項(即我們不創建該版本代碼使用的其它交付物) 。 理想情況下 , 這也意味著可以對管道中的流程進行版本控制和重建(請參閱稍后的 DevOps 討論) 。
  • 快速迭代:“快速”在這里是個相對術語 , 但無論軟件更新/發布的頻率如何 , 預期的持續過程都會以高效的方式將源代碼轉換為交付物 。 自動化負責大部分工作 , 但自動化處理的過程可能仍然很慢 。 例如 , 對于每天需要多次發布候選版更新的產品來說 , 一輪 集成測試(integrated testing)下來耗時就要大半天可能就太慢了 。
什么是“持續交付管道”?將源代碼轉換為可發布產品的多個不同的 任務(task)和 作業(job)通常串聯成一個軟件“管道” , 一個自動流程成功完成后會啟動管道中的下一個流程 。 這些管道有許多不同的叫法 , 例如持續交付管道、部署管道和軟件開發管道 。 大體上講 , 程序管理者在管道執行時管理管道各部分的定義、運行、監控和報告 。
持續交付管道是如何工作的?軟件交付管道的實際實現可以有很大不同 。 有許多程序可用在管道中 , 用于源代碼跟蹤、構建、測試、指標采集 , 版本管理等各個方面 。 但整體工作流程通常是相同的 。 單個業務流程/工作流應用程序管理整個管道 , 每個流程作為獨立的作業運行或由該應用程序進行階段管理 。 通常 , 在業務流程中 , 這些獨立作業是以應用程序可理解并可作為工作流程管理的語法和結構定義的 。
這些作業被用于一個或多個功能(構建、測試、部署等) 。 每個作業可能使用不同的技術或多種技術 。 關鍵是作業是自動化的、高效的 , 并且可重復的 。 如果作業成功 , 則工作流管理器將觸發管道中的下一個作業 。 如果作業失敗 , 工作流管理器會向開發人員、測試人員和其他人發出警報 , 以便他們盡快糾正問題 。 這個過程是自動化的 , 所以比手動運行一組過程可更快地找到錯誤 。 這種快速排錯稱為 快速失敗(fail fast) , 并且在抵達管道端點方面同樣有價值 。
“快速失敗”是什么意思?管道的工作之一就是快速處理變更 。 另一個是監視創建發布的不同任務/作業 。 由于編譯失敗或測試未通過的代碼可以阻止管道繼續運行 , 因此快速通知用戶此類情況非常重要 。 快速失敗指的是在管道流程中盡快發現問題并快速通知用戶的方式 , 這樣可以及時修正問題并重新提交代碼以便使管道再次運行 。 通常在管道流程中可通過查看歷史記錄來確定是誰做了那次修改并通知此人及其團隊 。

推薦閱讀