持續整合 - 降低風險
專案中可能會出現問題。透過有效地實踐 CI，您可以瞭解在開發週期中的每個步驟會發生什麼，而不是在專案進入開發週期後期才發現。CI 幫助您在風險發生時識別和降低風險，從而更容易根據具體證據評估和報告專案的健康狀況。
本節將重點關注使用持續整合可以避免的風險。
任何專案都存在許多需要管理的風險。透過在開發生命週期的早期消除風險，這些風險在系統實際上線時演變成問題的可能性就會降低。
風險 1 – 缺少可部署的軟體
“在我的機器上可以工作，但在其他機器上卻無法工作” – 這可能是任何軟體組織中最常見的短語之一。由於每天對軟體構建進行的更改數量眾多，有時人們對軟體構建是否真正有效缺乏信心。此問題有以下三個副作用。
對我們是否能夠構建軟體幾乎沒有信心。
在內部（即測試團隊）或外部（即客戶）交付軟體之前，整合階段很長，在此期間沒有其他工作完成。
無法生成和複製可測試的構建。
解決方案
消除 IDE 和構建流程之間的緊耦合。使用單獨的機器專門用於整合軟體。確保構建軟體所需的一切都包含在版本控制儲存庫中。最後，建立一個持續整合系統。
持續整合伺服器可以監視版本控制儲存庫中的更改，並在檢測到對儲存庫的更改時執行專案構建指令碼。持續整合系統的功能可以增強，包括讓構建執行測試、執行檢查以及在開發和測試環境中部署軟體；這樣您始終擁有一個可工作的軟體。
“無法與資料庫同步” – 有時開發人員無法在開發期間快速重新建立資料庫，因此難以進行更改。這通常是由於資料庫團隊和開發團隊之間存在分離造成的。每個團隊都專注於自己的職責，彼此之間的協作很少。此問題有以下三個副作用：
害怕更改或重構資料庫或原始碼。
難以使用不同的測試資料填充資料庫。
難以維護開發和測試環境（例如，開發、整合、QA 和測試）。
解決方案
解決上述問題的辦法是確保所有資料庫工件都放置在版本控制儲存庫中。這意味著重新建立資料庫模式和資料所需的一切：資料庫建立指令碼、資料操作指令碼、儲存過程、觸發器以及任何其他所需的資料庫資產。
透過刪除和重新建立資料庫和表，從構建指令碼中重建資料庫和資料。接下來，應用儲存過程和觸發器，最後插入測試資料。
測試（和檢查）您的資料庫。通常，您將使用元件測試來測試資料庫和資料。在某些情況下，您需要編寫特定於資料庫的測試。
風險 2 – 在生命週期後期發現缺陷
由於多個開發人員對原始碼進行了如此多的頻繁更改，因此程式碼中始終有可能引入缺陷，而這些缺陷可能只能在後期階段檢測到。在這種情況下，這可能會造成很大的影響，因為在軟體中檢測到的缺陷越晚，消除缺陷的成本就越高。
解決方案
迴歸測試 - 這是任何軟體開發週期的最重要方面，測試和再測試。如果對軟體程式碼進行任何重大更改，則絕對必須確保執行所有測試。這可以透過持續整合伺服器自動完成。
測試覆蓋率 - 如果測試用例沒有涵蓋程式碼的全部功能，那麼測試就沒有意義。必須確保建立的用於測試應用程式的測試用例是完整的，並且所有程式碼路徑都經過測試。
例如，如果您有一個需要測試的登入螢幕，您不能只建立一個成功登入的場景的測試用例。您需要有一個負面測試用例，其中使用者輸入不同的使用者名稱和密碼組合，然後需要檢視在這種情況下會發生什麼。
風險 3 – 缺乏專案可見性
手動通訊機制需要大量的協調才能確保及時地將專案資訊傳播給合適的人員。向旁邊的開發人員傾斜並讓他們知道最新的構建位於共享驅動器上非常有效，但它不能很好地擴充套件。
如果還有其他開發人員需要此資訊，而他們正在休息或無法訪問怎麼辦？如果伺服器宕機，您是如何得到通知的？有些人認為他們可以透過手動傳送電子郵件來降低這種風險。但是，這無法確保資訊在正確的時間傳遞給合適的人員，因為您可能會意外地遺漏感興趣的各方，而有些人可能當時無法訪問他們的電子郵件。
解決方案
解決此問題的辦法再次是持續整合伺服器。所有 CI 伺服器都具有在構建失敗時觸發自動電子郵件的功能。透過向所有關鍵利益相關者傳送此自動通知，還可以確保每個人都瞭解軟體的當前狀態。
風險 4 – 軟體質量低下
有缺陷，也有潛在缺陷。當您的軟體設計不佳或不符合專案標準，或者難以維護時，您可能會遇到潛在的缺陷。有時人們將其稱為程式碼或設計異味——“表明某些地方可能存在問題”。
有些人認為低質量的軟體僅僅是延遲的專案成本（交付後）。它可能是延遲的專案成本，但在您將軟體交付給使用者之前，它還會導致許多其他問題。過於複雜的程式碼、不遵循架構的程式碼以及重複的程式碼——通常都會導致軟體中的缺陷。在這些程式碼和設計異味演變成缺陷之前找到它們可以節省時間和金錢，並可以帶來更高質量的軟體。
解決方案
有一些軟體元件可以執行程式碼質量檢查，這些元件可以與 CI 軟體整合。這可以在程式碼構建後執行，以確保程式碼實際上符合正確的編碼指南。