Travis CI for newbies? What and how of it.

Why do stuff that can be automated :)

Automated dressing in Richie Rich

Let’s start from the root and that is automation. A task that can be performed without any human interference is said to be automated.

That’s the simple definition for ya’ll but this is not what I am writing this blog for. The main stuff is TravisCI (the CI in this stands for Continuous Integration).

Before we dive further let me clear few things. I’ll be using Node.js apps as a base to explain the usage of TravisCI. This blog only covers the tip of this tool only the basic, that’ll be enough on your first try.
If you are here to see the script you need to add in your repo head directly to the end ( but I won’t recommend that if your basics aren’t clear).

Now been said that ‘ikuzo’ ( let’s go )

What is CI?

CI - Continuous Integration. This technique is used in order to make changes to the project often, that is done by merging small chunks of code frequently instead of merging larger block at the end of a software development cycle.

(credits: travis-ci/docs site)

This is what CI in TravisCI stands for and this practice is the core of this tool.

What Travis is and what it does?

Travis-CI is a tools that practices Continuous Integration by automating Building, Testing and Deploying of your project while you focus on coding a masterpiece.

Now how it does all this?

1. It clones your repo. to a new environment (i.e. OS like linux, macOS or windows)
2. Runs all the test against your code if defined any.
3. Do build checks if one of it fails the build check is tagged as a failure if not, build check is passed.
4. After successful execution of all these steps, an optimised production build is created and if defined, your project is deployed to the provider of your choice (like GitHub pages).

This is what the log file looks like

Side note:

Build is made-up of stages. Stages are made-up of jobs and jobs in the end are made-up of phases.

A simple representation of build-stage-job-phase relation

Some main phases that a basic config has:

1. install: For installing all the dependencies needed for the project’s production build
2. Script: Here all the important scripts a executed like testing and building production build
3. deploy (optional): Here we decide our provider which means where we want to deploy our project like pages for GitHub pages.

“Note: We will be discussing in depth about how we can configure these phases according to our projects need”

Time for some hands-on work.

We’ve covered almost all the basics needed to understand what we’ll be doing when configuring Travis for our Node.js app.

Let’s get started with setting up our TravisCI account for our GitHub Repos.

Step 1:

Head to Travis-CI site for signing up with your GitHub account.

travis-ci sign-in

Step 2:

Authorize Travis-CI to access your account info in order to do build checks of your projects.

Authorize Travis CI

Step 3:

Once you have authorized Travis and signed into the site click on your avatar and head to settings to activate the Travis-CI app.

Step 4:

After you click activate, now you have to select where to install the app. All repos or a specific repo (This choice can be altered at any point of time in the future). This will decide on which repos Travis has access to do build checks and all.

Approve and install.

The .travis.yml file and steps before our first build check.

Now we have given Travis CI permission to access all of our repos or a specific one (that depends on you). After this we have to add a file named .travis.yml (.yml is the extension for YAML).

This file will contain all the configuration data we want to configure for our project and Travis-CI will look for this file in your projects repo in order to run the build checks. Therefore, the build checks will be carried out for all the merges done after this file is added to the repo.

Now, Before we dive deep into the configuration we have to generate a GitHub token in order to authenticate Travis-CI on behalf of us while carrying out all the build checks.This Token then will be added to the configuration file i.e. .travis.yml

Generating Token:

Head to your GitHub account’s setting page. And go to Developer Settings

Now go to Personal access tokens and Generate new Token.

Add a name to the token and check Public_repo (to give access to public repos only). And Generate the token. Once Generated, Copy the Token right away as you will not be able to see it again.

We’ll be needing this token in next and last step.

Now head to Travis-CI site and select the repo from the dashboard you want to install it in. Then go to setting of that repo from more options.

Now Scroll down to Environment Variables and create one with GITHUB_TOKEN as name and paste the Token (copied previously) in the value section. And click add.

The Configuring Part.

Now you are done with all the setting stuff, let’s get going with the config file .travis.yml .

Let’s start dissecting the code above.

Languages:

By default Travis sets Ruby as the default language for your project. But you can set to your desired one as we have done for our Node.js app

language: node_js
    node_js:  
        - 14.8.0

Here we define the language our project is written in and the version we need it to run on.

Caching:

Installing few dependencies over and over is time consuming why not use cache instead. So, the build do not install these dependencies over and spend unnecessary time instead use caching. We can turn it on by the following code and also set the directory in the directories property that needs to be cached for future (if changed).

We have to define which package manager will be used to do so. Here npm.

(Note: I hope I am correct on this one do let me now in the comments if you find something off).

cache:  
    npm: true  
    directories:    
        - node_modules

Installing and building:

To install all the dependencies we use specific commands like npm install in node apps. By default it is configured as npm install or npm ci . (in npm ci it checks for the existence of package-lock.json file, only then it installs all the stuff).

install:  
    - npm install

After all the dependencies are installed we need to create an optimized production build that later will be deployed on the server. Here also we use our defined script commands like npm run build that uses a specific bundler to build a production build.

script:  
    - npm run build

Deployment:

Here we’ll be using GitHub pages for deploying our project. These are called providers, there are different kinds of providers like AWS, Google Firebase and etc.

deploy:  
    provider: pages  
    skip_cleanup: true  
    github-token: $GITHUB_TOKEN  
    local_dir: build  
    on:    
        branch: main

We set our provider as pages. From this Travis knows that it has to deploy our project to GitHub pages.

**One more Important thing, do set skip_cleanup to true, as to prevent Travis from deleting all the files that have been changed or pushed before the creation of production build.

Do you remember creating an Environment Variable for GitHub Token? this is where we use it to deploy our code.

local-dir property is for letting Travis know that this is the directory which contains the production build and have to be pushed to the branch which will be hosted on GitHub Pages.

The last bit of code simply tells Travis that this is the branch where after every push/merge do a build check and deploy the code to GitHub Pages.

This is it Congratulations you’ve made it to the end and learned about CI/CD an awesome tool that’ll make your workflow smooth like a pro.

This blog is based on the info provided in the Documentation of Travis-CI. For Further in-depth understanding refer to the site HERE!!

Signing off Soyokaze ❤.