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


所有持續交付管道都應該被自動化嗎?管道的幾乎所有部分都是應該自動化的 。 對于某些部分 , 有一些人為干預/互動的地方可能是有意義的 。 一個例子可能是 用戶驗收測試(user-acceptance testing)(讓最終用戶試用軟件并確保它能達到他們想要/期望的水平) 。 另一種情況可能是部署到生產環境時用戶希望擁有更多的人為控制 。 當然 , 如果代碼不正確或不能運行 , 則需要人工干預 。
有了對“持續”含義理解的背景 , 讓我們看看不同類型的持續流程以及它們在軟件管道上下文中的含義 。
什么是“持續集成”?持續集成(CI)是在源代碼變更后自動檢測、拉取、構建和(在大多數情況下)進行單元測試的過程 。 持續集成是啟動管道的環節(盡管某些預驗證 —— 通常稱為 上線前檢查(pre-flight checks) —— 有時會被歸在持續集成之前) 。
持續集成的目標是快速確保開發人員新提交的變更是好的 , 并且適合在代碼庫中進一步使用 。
持續集成是如何工作的?持續集成的基本思想是讓一個自動化過程監測一個或多個源代碼倉庫是否有變更 。 當變更被推送到倉庫時 , 它會監測到更改、下載副本、構建并運行任何相關的單元測試 。
持續集成如何監測變更?目前 , 監測程序通常是像 Jenkins 這樣的應用程序 , 它還協調管道中運行的所有(或大多數)進程 , 監視變更是其功能之一 。 監測程序可以以幾種不同方式監測變更 。 這些包括:

  • 輪詢:監測程序反復詢問代碼管理系統 , “代碼倉庫里有什么我感興趣的新東西嗎?”當代碼管理系統有新的變更時 , 監測程序會“喚醒”并完成其工作以獲取新代碼并構建/測試它 。
  • 定期:監測程序配置為定期啟動構建 , 無論源碼是否有變更 。 理想情況下 , 如果沒有變更 , 則不會構建任何新內容 , 因此這不會增加額外的成本 。
  • 推送:這與用于代碼管理系統檢查的監測程序相反 。 在這種情況下 , 代碼管理系統被配置為提交變更到倉庫時將“推送”一個通知到監測程序 。 最常見的是 , 這可以以 webhook 的形式完成 —— 在新代碼被推送時一個 掛勾(hook)的程序通過互聯網向監測程序發送通知 。 為此 , 監測程序必須具有可以通過網絡接收 webhook 信息的開放端口 。
什么是“預檢查”(又稱“上線前檢查”)?在將代碼引入倉庫并觸發持續集成之前 , 可以進行其它驗證 。 這遵循了最佳實踐 , 例如 測試構建(test build)和 代碼審查(code review) 。 它們通常在代碼引入管道之前構建到開發過程中 。 但是一些管道也可能將它們作為其監控流程或工作流的一部分 。
例如 , 一個名為 Gerrit 的工具允許在開發人員推送代碼之后但在允許進入( Git 遠程)倉庫之前進行正式的代碼審查、驗證和測試構建 。 Gerrit 位于開發人員的工作區和 Git 遠程倉庫之間 。 它會“接收”來自開發人員的推送 , 并且可以執行通過/失敗驗證以確保它們在被允許進入倉庫之前的檢查是通過的 。 這可以包括檢測新變更并啟動構建測試(CI 的一種形式) 。 它還允許開發者在那時進行正式的代碼審查 。 這種方式有一種額外的可信度評估機制 , 即當變更的代碼被合并到代碼庫中時不會破壞任何內容 。
什么是“單元測試”?單元測試(也稱為“提交測試”) , 是由開發人員編寫的小型的專項測試 , 以確保新代碼獨立工作 。 “獨立”這里意味著不依賴或調用其它不可直接訪問的代碼 , 也不依賴外部數據源或其它模塊 。 如果運行代碼需要這樣的依賴關系 , 那么這些資源可以用 模擬(mock)來表示 。 模擬是指使用看起來像資源的 代碼存根(code stub) , 可以返回值 , 但不實現任何功能 。
在大多數組織中 , 開發人員負責創建單元測試以證明其代碼正確 。 事實上 , 一種稱為 測試驅動開發(test-driven develop)(TDD)的模型要求將首先設計單元測試作為清楚地驗證代碼功能的基礎 。 因為這樣的代碼可以更改速度快且改動量大 , 所以它們也必須執行很快 。
由于這與持續集成工作流有關 , 因此開發人員在本地工作環境中編寫或更新代碼 , 并通單元測試來確保新開發的功能或方法正確 。 通常 , 這些測試采用斷言形式 , 即函數或方法的給定輸入集產生給定的輸出集 。 它們通常進行測試以確保正確標記和處理出錯條件 。 有很多單元測試框架都很有用 , 例如用于 Java 開發的 JUnit 。
什么是“持續測試”?持續測試是指在代碼通過持續交付管道時運行擴展范圍的自動化測試的實踐 。 單元測試通常與構建過程集成 , 作為持續集成階段的一部分 , 并專注于和其它與之交互的代碼隔離的測試 。

推薦閱讀