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


除此之外 , 可以有或者應該有各種形式的測試 。 這些可包括:

  • 集成測試 驗證組件和服務組合在一起是否正常 。
  • 功能測試 驗證產品中執行功能的結果是否符合預期 。
  • 驗收測試 根據可接受的標準驗證產品的某些特征 。 如性能、可伸縮性、抗壓能力和容量 。
所有這些可能不存在于自動化的管道中 , 并且一些不同類型的測試分類界限也不是很清晰 。 但是 , 在交付管道中持續測試的目標始終是相同的:通過持續的測試級別證明代碼的質量可以在正在進行的發布中使用 。 在持續集成快速的原則基礎上 , 第二個目標是快速發現問題并提醒開發團隊 。 這通常被稱為快速失敗 。
除了測試之外 , 還可以對管道中的代碼進行哪些其它類型的驗證?除了測試是否通過之外 , 還有一些應用程序可以告訴我們測試用例執行(覆蓋)的源代碼行數 。 這是一個可以衡量代碼量指標的例子 。 這個指標稱為 代碼覆蓋率(code-coverage) , 可以通過工具(例如用于 Java 的 JaCoCo )進行統計 。
還有很多其它類型的指標統計 , 例如代碼行數、復雜度以及代碼結構對比分析等 。 諸如 SonarQube 之類的工具可以檢查源代碼并計算這些指標 。 此外 , 用戶還可以為他們可接受的“合格”范圍的指標設置閾值 。 然后可以在管道中針對這些閾值設置一個檢查 , 如果結果不在可接受范圍內 , 則流程終端上 。 SonarQube 等應用程序具有很高的可配置性 , 可以設置僅檢查團隊感興趣的內容 。
什么是“持續交付”?持續交付(CD)通常是指整個流程鏈(管道) , 它自動監測源代碼變更并通過構建、測試、打包和相關操作運行它們以生成可部署的版本 , 基本上沒有任何人為干預 。
持續交付在軟件開發過程中的目標是自動化、效率、可靠性、可重復性和質量保障(通過持續測試) 。
持續交付包含持續集成(自動檢測源代碼變更、執行構建過程、運行單元測試以驗證變更) , 持續測試(對代碼運行各種測試以保障代碼質量) , 和(可選)持續部署(通過管道發布版本自動提供給用戶) 。
如何在管道中識別/跟蹤多個版本?版本控制是持續交付和管道的關鍵概念 。 持續意味著能夠經常集成新代碼并提供更新版本 。 但這并不意味著每個人都想要“最新、最好的” 。 對于想要開發或測試已知的穩定版本的內部團隊來說尤其如此 。 因此 , 管道創建并輕松存儲和訪問的這些版本化對象非常重要 。
在管道中從源代碼創建的對象通??梢苑Q為 工件(artifact) 。 工件在構建時應該有應用于它們的版本 。 將版本號分配給工件的推薦策略稱為 語義化版本控制(semantic versioning) 。 (這也適用于從外部源引入的依賴工件的版本 。 )
語義版本號有三個部分: 主要版本(major)、 次要版本(minor) 和 補丁版本(patch) 。 (例如 , 1.4.3 反映了主要版本 1 , 次要版本 4 和補丁版本 3 。 )這個想法是 , 其中一個部分的更改表示工件中的更新級別 。 主要版本僅針對不兼容的 API 更改而遞增 。 當以 向后兼容(backward-compatible)的方式添加功能時 , 次要版本會增加 。 當進行向后兼容的版本 bug 修復時 , 補丁版本會增加 。 這些是建議的指導方針 , 但只要團隊在整個組織內以一致且易于理解的方式這樣做 , 團隊就可以自由地改變這種方法 。 例如 , 每次為發布完成構建時增加的數字可以放在補丁字段中 。
如何“分銷”工件?團隊可以為工件分配 分銷(promotion)級別以指示適用于測試、生產等環境或用途 。 有很多方法 。 可以用 Jenkins 或 Artifactory 等應用程序進行分銷 。 或者一個簡單的方案可以在版本號字符串的末尾添加標簽 。 例如 , -snapshot 可以指示用于構建工件的代碼的最新版本(快照) 。 可以使用各種分銷策略或工具將工件“提升”到其它級別 , 例如 -milestone 或 -production , 作為工件穩定性和完備性版本的標記 。
如何存儲和訪問多個工件版本?從源代碼構建的版本化工件可以通過管理 工件倉庫(artifact repository)的應用程序進行存儲 。 工件倉庫就像構建工件的版本控制工具一樣 。 像 Artifactory 或 Nexus 這類應用可以接受版本化工件 , 存儲和跟蹤它們 , 并提供檢索的方法 。
管道用戶可以指定他們想要使用的版本 , 并在這些版本中使用管道 。
什么是“持續部署”?持續部署(CD)是指能夠自動提供持續交付管道中發布版本給最終用戶使用的想法 。 根據用戶的安裝方式 , 可能是在云環境中自動部署、app 升級(如手機上的應用程序)、更新網站或只更新可用版本列表 。

推薦閱讀