I decided to check Travis CI for my github projects. I’ve heard many good opinions about it, so decided to do read a bit. This post is about what I found out.
Short reminder what is CI
CI (Continuous Integration) is a development practice of checking quality and integration of software continuously. For development team it’s usually a tool which is integrated with their code repository, which builds their application every commit. This tool can also run tests, check code style, etc. I think the most popular tool for this is Jenkins - it can be used for every code base. There are also some tools for each repository platform, for example: Travis CI for GitHub or GitLab CI (their pipelines looks really promising…).
Travis CI
To start you need to have an account on GitHub and on Travis CI platform. Also it’s nice to have a repository for which you want to use continuous integration.
On Travis CI web page find your profile - if you want to enable Travis CI for your repository just change a switch. This is how it looks for me:
After enabling Travis CI support for your repository, you need to
add .travis.yml
file to it and trigger a build by pushing
some commits.
Travis CI environment
For every build there is a fresh instance of virtual machine used, so you start from scratch every time. By default it uses Ubuntu 12.04 or 14.04 LTS 64-bit edition. It is also possible to run build under OS X somehow. Windows is not supported .
There are many pre-installed
tools you can use - for example wget
or curl
. Multiple data stores can be used,
for instance PostgreSQL, MySQL, Redis, Cassandra, MongoDB, etc.
I was surprised that even there is a support for browser (currently only Firefox)
and messaging queues (RabbitMQ or ZeroMQ). There are plenty configuration
options, tools and things you can define for your build.
Magic .travis.yml file
This magic .travis.yml
file is for defining how to build your project.
It has to
be in yaml
format - it’s similar to json
, but with indents instead of brackets.
This makes it more human readable.
Not all technologies are supported by Travis CI. Here is a list of supported languages. It’s allowed to add support for new languages - you just need to gather a small team (3 people) and create PR to Travis CI project following their guidelines.
.travis.yml
should have three parts:
- language declaration
- install definition
- script definition
There can also be a part deploy
, but it’s optional and I did’t
use it. I’ve read it can even deploy something on github pages or
amazon services, so it’s worth checking.
You can set up environment variables using env
tag.
Language definition
For Travis CI it’s important that you declare in what language is your project - it defines which version of virtual machine image builder will use. It will set up default runtime for this language. It’s possible to use multiple programming languages in your build, but you need to add others as dependencies. Anyway, on every virtual machine there is support for Python, Ruby, Node.js and GO. Also OpenJDK is supported be default.
Build matrix
When you declare runtime, you can use multiple versions, for example:
language: erlang
otp_release:
- 18.2.1
- 18.1
- 18.0
- 17.5
Project with settings above will be build for all of there versions of otp (this part is custom for all languages, so for instance for Ruby you can declare rvm version, etc). When you add also some environment variables:
env:
- DB=postgres
- DB=mysql
it will perform builds against all possible configurations, so 8 builds - for each version of otp and for each environment variables declaration.
If your build matrix becomes too big, it’s possible to exclude some configurations.
Install part of Travis CI configuration
Install part is for defining what dependencies are to be installed before running build. For example it can look like this:
install: ./install-dependencies.sh
There is also before_install
step in which
you can define for example what other Ubuntu Packages you want to install before
dependencies. If you want to skip install part just
do:
install: true
Note that every command in this part has to succeed to continue your build, otherwise your build will finish with error status.
Script part of Travis CI configuration
Script part of project is for running building script, tests or
other checks.
How script part looks depends on a project language. For example for Erlang
it will use rebar
by default, for Python pip
and for GO make go-deps
which
should be defined in your Makefile
. You can also define which steps
should be done in after_script
or before_script
.
When one of script
commands fails, Travis CI will continue and accumulate
the result. So if for running all tests, you need multiple commands, don’t worry,
you’ll see all fails .
Conclusion
Travis CI seems to be a powerful tool. There is support for the most known technologies, but I’m not sure what happens when you use something obscure. On the other side there are plenty technologies on supported tools list… Also it’s possible to extend Travis CI with new ones, but you have to do it by yourself (or find someone who will do it).
Configuration seems to be fairly simple and gives plenty options, but it’s also easy to start, unless you have some legacy project. Also I think documentation is very good - it’s easy to understand what’s going on and why. Maybe default options should be stressed more clearly. For me Travis CI is definitely worth checking more.
Leave a Comment