One Configuration File

The configuration file for Travis is written in the yml format. YAML is responsible for this format - a universal language for presenting data in an appropriately structured way. The configuration file should be named .travis.yml.

At the beginning, however, we need to determine what kind of project will be connected with Travis (in this article I will present an example based on nodejs) and define the procedures we will follow while working on our project. The vast majority of projects are built using the GIT version control system. In repositories of this type, the main branch is most often master, which is directly connected with the production version of the application. The dev or develop branch, and I have also encountered the workspace version, is equivalent to the development version of the code we are working on. So it is clear that in our procedure we should include at least two versions: production and development, by connecting code from individual branches with the appropriate environment. It is also often the case that both versions are located on different servers. Fortunately, Travis allows us to include all of this in its configuration.

Basic Configuration

The language field should contain information about the language in which we will carry out the process of building our application. The second field will point us to the node_js version we want to use. The third field we will use in our example is cache. Here we can indicate which directories should be passed to the cache in order to reduce the resources needed to perform the whole process in the future - in our case, downloading all npm packages every time will rather be an unnecessary step.

language: node_js
node_js:
  - "stable"
cache:
  directories:
    - node_modules

Process

Travis divides the whole build process into phases. In the documentation, this is called the process lifecycle. There are two main phases in the lifecycle:

• install - during this phase the whole environment is prepared and all necessary dependencies are installed
• script - during this phase the build process is launched

Apart from the two main phases, we can distinguish additional phases, such as:

• before_install
• before_script
• after_script
• after_success
• after_failure

These are phases that will always occur. Apart from them, we can also distinguish optional phases, for example:

• before_cache
• before_deploy
• deploy
• after_deploy.

Quite a lot, right? Understanding what the build process looks like allows us to plug into different phases of the whole process lifecycle and add new tasks, control the process, and detect errors that we probably would not catch on our own.

Look at the example below. I indicated that the following tasks should be performed in the script phase: npm run test and npm run build. They will be performed in the order in which they are listed. If the tests fail, the process will be interrupted, and in the Travis panel we will see a red message about a failed process. The same applies to every task you indicate for execution.

script:
	- npm test
	- npm run build