在 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 的原创文章，尽在：” 汪子熙 ”: