共计 803 个字符，预计需要花费 3 分钟才能阅读完成。
解释 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 的原创文章，尽在：” 汪子熙 ”:
正文完
