(Note:- The post was migrated from the previous blog written on 17th November 2017 web.arvhive.org). That was a lossy migration and the images were not be able to recover using webarchive. See what happend to the previous blog

After working with Jenkins at Interblocks, I really wanted to try something similar continuous integration tool for works. What is Continuous Integration?. The name itself defines what it is. It is basically a methodology used by the developers when they are working as a team. Whenever a team member commits a change to the repository that they are using, we can verify the new commit by an automated build. We can run some tests on that automated build using scripts. That’s the simplest idea. It will help to identify the mistakes and errors done by the programmers before merging to the branch. Ok fine. Then why TravisCI over jenkins. Though Jenkins seems cool and familiar, as I’m not usually working with JavaEE in daily basis, I wanted to do something related to nodeJs. Is that the only reason?. Not exactly actually Node project can be built with jenkins. But TravisCI is prefered over Jenkins based on some reasons and I’ve listed them below. In my case I got a Free Ticket :D. Student are given the facility to use TravisCI commercial version under the Github Student Pack. Github with the collaboration of some of the industry giants, provides a really good opportunity to try the paid tools free. Here is the link and give it a try. I have used Github private repo pack, Namecheap domain pack, digital Ocean pack and planning to use Strip with a future projects.(Also there is another CI tool called Bamboo by atlassian and they are also providing it under their classroom package. Honestly I’ve never Tried it yet).

Travis CI and Jenkins.

Jenkins	TravisCI
Suits for large project	Suits for open source projects
Free	Pro version has more features
Dedicated server is needed(You have to host it )	No need of dedicated servers(It is already hosted)
Configuring takes time	No need of dedicated servers(It is already hosted)

# TravisCI

Travis CI is a hosted continuous integration and deployment system. As I mentioned before you do not need to host it by yourself you can use it as a SaaS. Like WordPress.com and WordPress.org,There are two versions of it, travis-ci.com (Travis Pro) for private repositories, and travis-ci.org for public repositories.

Basics

To build a project using TravisCI we have to have a .travis.yml in our repository. Basically that includes the metadata about the project as well as the scripts that we are hoping to run to test after building the branch. I will show you a one in the demo. Let’s drive bit deep. There are few common terms in TravisCI and it’s better to be familiarise with them. A deployment is called a job which has several intermediate, sequential tasks called phases and the main phases would be install,script,deploy those also will be covered in the demo. There is another term called “Build” which implements a group of tasks. To understand “Stage” term have a look at the below image.

Figure – Stage

### Process

First creating a virtual environment for the app. Second cloning the repository into the virtual environment. Build the project. Run the test cases.

### Supporting Languages

TravisCI supports a range of languages. Here are some of them. Julia, Objective-C, Perl, Perl6, PHP, Python, R, Ruby, Rust, Scala, Smalltalk, Visual Basic.Android, C, C#, C++, Clojure, Crystal, D, Dart, Erlang, Elixir, F#, Go, Groovy Haskell, Haxe, Java, JavaScript (with Node.js).

# DEMO

I’m just trying to deploy a simple nodeJS application using TravisCI. For this I’m going to use travis-ci.com. As I mentioned before, first of all I have to write a .travis.yml to my repo and commit it . This is my sample yml file

.travis.yml

If there is not such a command TravisCI will automatically run “npm test” command which is specified in the “package.json” file. This command will be created automatically when you are initiating npm. This is it

Figure – Package.json

So far so good but why It is not building :/ .After doing a bit diving, I found the reason. Whenever a phase returns a non zero exit code, the TravisCI will think that as an “Ërror” . The default code is “”1”, So we have to change it to “0”. So here is my final result.

Figure – Build Success

Hooorayyyyyyyyyyyyyyyyyyyyyyyyyyyy

So it succeeded, But by changing only the value to “1”, can we guarantee that the project built successfully? No for that you have to run real test cases. But for this one I did something else. I wrote a script in travis.yml to start the node server.

Figure – Running the node server.

The server started perfectly(that means the project is successfully built) but did not get the green sign. It was running for around 10 minutes and gave a build failure. Actually this failure doesn’t mean that we did something wrong. Just running the server will not give neither 1 nor 0 at the end of the execution. So t he test runs for the previously configured time and then stops after getting a timeout. That why it get failed. So we can be happy for now.

Important facts

When you do a change in github, sometimes it won’t sync with travisCI for manual building. For this reason I recommend to sync manually every time when you do a change to the code For that follow below steps.

In the left corner tap the plus sign

Figure – Select Syncing

Then tap the syncing button(IF you hover over you will see the last synced time)

Figure – Sync

Cool features

Adding to build status

You may have seen some badges in the Readme files in some Github repositories saying the build is passed. It gives some kind of good vibes to the person who is going to use your code.

Figure Build Passing tag in readme.md

To add this. First tap on the build sign on the top to the page

Figure – On the top of the project

Then you get the image links related to your build.

Figure – Image links related to the build

Go to the readme.md and edit the link as follows.

Verifying the commits.

Wait a second. Why were we going to use CI in the first place??. To automate the build right? Do you see anything automated here. No. That is we did this for just for a demo. Actually each time when you are committing Travis CI will automatically build them. Actually this manually building that we just did is a beta feature that Travis is providing. If you select any file in your Github repo and go it’s its history you will see something like this.

Figure -Auto building

It will show the end result of your builds. Saying whether they passed or not. These will be available for every pull request too. So you can be sure about the code that you are going to merge to your repository. That’s all for today. Will meet with a new article soon. Bye.