依賴管理

不同專案所用的版本號其具體含義並不完全相同，但是一個相對比較常用的標準是語義版本號，這種版本號具有不同的語義，它的格式是這樣的：主版本號.次版本號.補丁號。相關規則有：

• 如果新的版本沒有改變 API，請將補丁號遞增；
• 如果您添加了 API 並且該改動是向後相容的，請將次版本號遞增；
• 如果您修改了 API 但是它並不向後相容，請將主版本號遞增。

這麼做有很多好處。現在如果我們的專案是基於您的專案構建的，那麼只要最新版本的主版本號只要沒變就是安全的 ，次版本號不低於之前我們使用的版本即可。換句話說，如果我依賴的版本是1.3.7，那麼使用1.3.8、1.6.1，甚至是1.3.0都是可以的。如果版本號是 2.2.4

使用依賴管理系統的時候，您可能會遇到鎖檔案（lock files）這一概念。鎖檔案列出了您當前每個依賴所對應的具體版本號。通常，您需要執行升級程式才能更新依賴的版本。這麼做的原因有很多，例如避免不必要的重新編譯、建立可復現的軟體版本或禁止自動升級到最新版本（可能會包含 bug）。還有一種極端的依賴鎖定叫做 vendoring

---

持續整合系統

隨著您接觸到的專案規模越來越大，您會發現修改程式碼之後還有很多額外的工作要做。您可能需要上傳一份新版本的文件、上傳編譯後的檔案到某處、釋出程式碼到 pypi，執行測試套件等等。或許您希望每次有人提交程式碼到 GitHub 的時候，他們的程式碼風格被檢查過並執行過某些基準測試？如果您有這方面的需求，那麼請花些時間瞭解一下持續整合。

持續整合，或者叫做 CI 是一種雨傘術語（umbrella term，涵蓋了一組術語的術語），它指的是那些“當您的程式碼變動時，自動執行的東西”，市場上有很多提供各式各樣 CI 工具的公司，這些工具大部分都是免費或開源的。比較大的有 Travis CI、Azure Pipelines 和 GitHub Actions。它們的工作原理都是類似的：您需要在程式碼倉庫中新增一個檔案，描述當前倉庫發生任何修改時，應該如何應對。目前為止，最常見的規則是：如果有人提交程式碼，執行測試套件。當這個事件被觸發時，CI 提供方會啟動一個（或多個）虛擬機器，執行您制定的規則，並且通常會記錄下相關的執行結果。您可以進行某些設定，這樣當測試套件失敗時您能夠收到通知或者當測試全部通過時，您的倉庫主頁會顯示一個徽標。

本課程的網站基於 GitHub Pages 構建，這就是一個很好的例子。Pages 在每次master有程式碼更新時，會執行 Jekyll 部落格軟體，然後使您的站點可以通過某個 GitHub 域名來訪問。對於我們來說這些事情太瑣碎了，我現在我們只需要在本地進行修改，然後使用 git 提交程式碼，釋出到遠端。CI 會自動幫我們處理後續的事情。

測試簡介

多數的大型軟體都有“測試套件”。您可能已經對測試的相關概念有所瞭解，但是我們覺得有些測試方法和測試術語還是應該再次提醒一下：

• 測試套件：所有測試的統稱。
• 單元測試：一種“微型測試”，用於對某個封裝的特性進行測試。
• 整合測試：一種“巨集觀測試”，針對系統的某一大部分進行，測試其不同的特性或元件是否能協同工作。
• 迴歸測試：一種實現特定模式的測試，用於保證之前引起問題的 bug 不會再次出現。
• 模擬（Mocking）: 使用一個假的實現來替換函式、模組或型別，遮蔽那些和測試不相關的內容。例如，您可能會“模擬網路連線” 或 “模擬硬碟”。