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