在 Github 專案資料夾下面新增 .travis.yml 檔案。

為了執行構建，Travis CI 的系統將觸發構建的儲存庫克隆到構建環境。 構建環境是一個隔離的虛擬機器或 LXD 容器，一旦構建完成就會終止。 克隆僅在構建請求之後發生，因此僅適用於在 GitHub 設定中明確啟用的儲存庫。

一個例子：

為了設定構建環境並準備構建，Travis CI 的系統從儲存庫和構建請求中明確指定的分支中獲取並處理 .travis.yml 配置檔案，由 GitHub 觸發。

這個 .travis.yml 配置檔案的語法在官網可以找到。

比如，dist: bionic 的意思是，構建虛擬系統的型別，bionic 是其中一個列舉值。

Travis CI 支援 Linux 構建的兩種虛擬化型別：“Full VM”和“LXD”。 最重要的是，Linux 構建可以在多個 CPU 架構上執行。

Full VM 是啟用 sudo 的，每個構建的完整虛擬機器，執行 Linux.

雖然啟動緩慢（與 LXD 容器相比增加了構建時間）但沒有任何限制。

它分配了固定數量的 vCPU 和 RAM。

而 LXD 環境，儘可能接近容器世界中的虛擬機器。 Linux 環境在非特權 LXD 容器中執行。

和 Full VM 相比，其啟動速度更快（與完整 VM 相比減少了構建時間）但確實存在一些限制。

它從最少 2 個 vCPU 開始，如果有更多的計算時間可用，主機可以動態分配它以加快構建速度。

又比如 branches 關鍵字和 only 的組合，下列例子的語義是，僅當 develop, epic, release, integration-libs 等 分支出現程式碼提交時才觸發 Travis.

.travis.yml 是一個 YAML 格式的配置檔案，下面是一些高階用法。

在更高階的用例中，為了減少大型構建配置檔案中的重複，一個好的做法是使用 YAML 的機制來定義和重用共享配置部分作為 YAML 錨點和別名。

例如，不要像這樣為兩個不同的部署目標重複部署配置, 這是不好的實踐：

deploy:
- provider: heroku
  api_key: ...
  app: app-production
  on:
    branch: master
- provider: heroku
  api_key: ...
  app: app-staging
  on:
    branch: staging
 

使用下列的語法，重用某塊 yaml 定義：

deploy:
- &deploy
  provider: heroku
  api_key: ...
  app: app-production
  on:
    branch: master
- <<: *deploy
  app: app-staging
  on:
    branch: staging

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