解釋 Travis CI 的最簡單方法是，每次提交到 GitHub 時它都會執行程式的測試（這可以通過多種方式進行配置，並且您始終可以在某些分支上禁用構建）。 這樣做的重點是，你通常可以很快發現你的提交是否破壞了某些東西，並在它成為問題之前修復它。 我建議在每個有單元測試的 GitHub 儲存庫上執行 Travis CI，並且使用 Travis CI 支援的程式語言。 由於設定 Travis CI 非常簡單，我通常認為沒有理由不使用它，除非您不在乎您的程式是否通過了測試。

Travis 的官網。

當您執行構建時，Travis CI 會將您的 GitHub 儲存庫克隆到一個全新的虛擬環境中，並執行一系列任務來構建和測試您的程式碼。

Jerry：因此在本地筆記本上執行這一切沒有意義？

如果其中一項或多項任務失敗，則構建被視為損壞。 如果沒有任何任務失敗，則認為構建已通過，Travis CI 可以將您的程式碼部署到 Web 伺服器或應用程式主機。

CI 構建還可以自動化交付工作流程的其他部分。 這意味著您可以使用 Build Stages 使作業相互依賴、設定通知、在構建後準備部署以及許多其他任務。

在 Travis CI 文件中，一些常用詞有特定的含義：

• build：一組按順序執行的作業(jobs)。 例如，一個構建可能有兩個作業(job)，每個作業都使用不同版本的程式語言測試一個專案。 當它的所有工作完成時，構建就完成了。

下圖是 Travis 上 build 的一個例子：

• stage：作為由多個階段組成的順序構建過程的一部分並行執行的一組作業。

stage 的例子。

• job：將您的儲存庫克隆到虛擬環境中的自動化過程，然後執行一系列階段，例如編譯程式碼、執行測試等。如果指令碼階段的返回程式碼非零，則作業失敗。這一點和 Linux API 的返回值設計很像。

job 的一個實際例子：

• phase：作業的連續步驟。 例如，安裝階段在指令碼階段之前，在可選的部署階段之前。

更多Jerry的原創文章，盡在："汪子熙":