Introduction to some special terms of Travis CI

The easiest way to explain Travis CI is that it runs your program's tests every time you commit to GitHub (this can be configured in a number of ways, and you can always disable builds on certain branches). The point of this is that you can usually quickly find out if your commit broke something and fix it before it becomes a problem. I recommend running Travis CI on every GitHub repository that has unit tests, and using a Travis CI supported programming language. Since it's so easy to set up Travis CI, I generally see no reason not to use it unless you don't care if your program passes the tests.

Travis's official website .

When you run a build, Travis CI clones your GitHub repository into a fresh virtual environment and performs a series of tasks to build and test your code.

Jerry: So it doesn't make sense to do all this on a local notebook?

If one or more of these tasks fails, the build is considered broken. If no tasks fail, the build is considered passed and Travis CI can deploy your code to a web server or application host.

CI builds can also automate other parts of the delivery workflow. This means that you can use Build Stages to make jobs depend on each other, set up notifications, prepare for deployment after a build, and many other tasks.

In Travis CI documentation, some common words have specific meanings:

• build: A set of jobs to run sequentially. For example, a build might have two jobs, each of which tests a project using a different version of the programming language. The build is complete when all its work is done.

The following picture is a example on Travis:

• stage: A set of jobs that run in parallel as part of a sequential build process consisting of multiple stages.

example of stage .

• your repository into a 161d983d95448a virtual environment and then performs a series of stages such as compiling code, running tests, etc. If the return code script stage is non-zero, the job fails. This is very similar to the return value design of the Linux API.

A practical example of a job:

• phase: Consecutive steps of the job. For example, the install phase precedes the script phase and the optional deploy phase.

More Jerry's original articles, all in: "Wang Zixi":