This is a short article on setting up Travis CI for your project on Github.
“Simply put, things always had to be in a production-ready state: if you wrote it, you darn well had to be there to get it running!” — Mike Miller
In order to be production ready you have to continually test your code to figure out any integration issues before hand. So what if, you can test your code immediately after you push it and also automate the process so that all your tests for your project run immediately after any commit made to your repository on Github. In case of any impending issues your commit could make, the tests triggered by the CI build process would fail indicating that there is a need to revisit your code or tests much earlier in the release process.
Travis is a CI build tool available for your Github projects for free. It will build your app and run your tests each time you make a push to the repository and most importantly it is open source.
I have a ASP.NET Web API project on Github and for the sake of the article I have written a unit test using the MS Test Framework although my preferred test framework is XUnit.
Once you have written the test, all you need to do is write a ‘.travis.yml’ file on the root path of your project. This file will contain all the configurations Travis needs to build and run the tests written in your project.
This is the my .travis.yml for my project.
The path in the solution is the path to my .sln file from directory where .travis.yml exists.
Once you push this all you need to do is:
3. Once you do that, you are going to see a consent screen if this is your first time. Read the permissions carefully and make sure you are okay with Travis accessing the data it requires before you continue.
4. After that, Travis will list all your repositories with a flick switch like this
You can flick the switch on for the repository you would like to set up the CI for. Here, I have already flicked it on for the project in question for this article.
5. Once you flick it on, Travis will start its magic and begin to build and run your tests based on the configuration provided in the .travis.yml file and after its done weaving its magic, Voila! If all your tests are passing, you will see something like this, in case of failure you can view the command line output and logs for what went wrong. The messages are mostly developer friendly and easy to make some sense out of it.
6. Most teams like to have their build status in their Github repo’s readme file so that the status of the current build can be shown when someone visits there. In order to do that just click this button on the top, select the markdown option and paste the code to your ‘README.md’ file option and push the changes to your repo.
In case you have projects in different environments like node using the karma platform and mocha test framework for example, the procedure to set up Travis for CI is exactly similar. The only thing that will change is your .travis.yml file. I have another repo which has karma and mocha tests for which I have set up the Travis CI already. Here is the config for the same.
That is it! That is all it takes.
If you have made it this far, Thank You!. All suggestions to improve this article and your thoughts are welcomed.