持續整合 - 需求

以下是持續整合最重要的需求列表。

• 定期簽入 − 持續整合正常執行的最重要實踐是頻繁簽入到原始碼儲存庫的主幹或主線。程式碼簽入應每天至少進行幾次。定期簽入帶來了許多其他好處。它使更改更小，因此不太可能破壞構建。這意味著當後續構建中出現錯誤時，可以知道要恢復到的最新軟體版本。

  它還有助於更有條理地進行程式碼重構，並堅持進行保留行為的小更改。它有助於確保更改大量檔案的可能性較小會與其他人的工作衝突。它允許開發人員更具探索性，嘗試想法並透過恢復到上次提交的版本來丟棄它們。

• 建立全面的自動化測試套件 − 如果您沒有全面的自動化測試套件，則透過構建僅表示應用程式可以編譯和組裝。雖然對於某些團隊來說，這是一個很大的進步，但必須進行一定程度的自動化測試才能確信您的應用程式實際上正在執行。

  通常，持續整合中進行3種類型的測試，即單元測試、元件測試和驗收測試。

  單元測試用於測試應用程式中小型程式碼片段的隔離行為。它們通常可以在不啟動整個應用程式的情況下執行。它們不會訪問資料庫（如果您的應用程式有資料庫）、檔案系統或網路。它們不需要您的應用程式在類似生產的環境中執行。單元測試應該執行得非常快——即使對於大型應用程式，整個套件也應該能夠在十分鐘內執行完畢。

  元件測試測試應用程式的多個元件的行為。與單元測試一樣，它們並不總是需要啟動整個應用程式。但是，它們可能會訪問資料庫、檔案系統或其他系統（可能被存根）。元件測試通常需要更長的執行時間。

• 保持構建和測試過程簡短 − 如果構建程式碼和執行單元測試花費太長時間，您將遇到以下問題。

  • 人們將停止進行完整的構建，而會在簽入之前執行測試。您將開始獲得更多失敗的構建。

  • 持續整合過程將花費很長時間，以至於在您可以再次執行構建之前，可能已經進行了多次提交，因此您將不知道哪個簽入破壞了構建。

  • 人們會減少簽入頻率，因為他們必須等待很長時間才能構建軟體並執行測試。

• 不要在損壞的構建上籤入 − 持續整合的最大錯誤是在損壞的構建上籤入。如果構建中斷，則負責的開發人員將等待修復它。他們儘快找出中斷的原因並修復它。如果我們採用這種策略，我們將始終處於最佳位置來找出導致中斷的原因並立即修復它。

  如果我們的同事進行了簽入，結果破壞了構建，那麼為了最大限度地修復它，他們將需要清晰地解決問題。當違反此規則時，構建的修復時間不可避免地會長得多。人們習慣於看到構建中斷，很快您就會陷入構建始終中斷的情況。

• 在提交之前始終在本地執行所有提交測試 − 始終確保首先在本地計算機上執行為應用程式設計的測試，然後再在CI伺服器上執行它們。這是為了確保編寫正確的測試用例，如果CI過程中出現任何故障，則是因為測試結果失敗。

• 對因您的更改而導致的所有中斷負責 − 如果您提交更改並且您編寫的所有測試都透過，但其他測試中斷，則構建仍然中斷。通常這意味著您已嚮應用程式引入了迴歸錯誤。這是您的責任——因為您進行了更改——修復由於您的更改而未透過的所有測試。在CI的上下文中，這似乎很明顯，但實際上在許多專案中這並不是一種常見的做法。