Hello my dear friends. Today we will talk about Travis-CI testing and how to speed up testing for ruby projects.
Caching .bundle directory
For many ruby projects a lot of time for preparing a build are spend by Travis-CI. The main reason for this is the installation of the required gems for your project. Eric Barendt and Matias Korhonen found a good solution for this problem - caching all needed gems in AWS S3. For this purpose they created bundle_cache gem. Let’s setup it.
First of all, you need AWS credentials and you should create the AWS S3 bucket, where cached gems will be stored. This gem need to set some environment variables.
So we need change our .travis.yml file in project:
Main commands are located in the keys “before_install”, “bundler_args”, “env” and “after_script”. Let’s analyze what each command are doing:
Also you’ll need to add your AWS credentials to a secure section there. Adding of this credentials is simple:
Install the travis gem using command gem install travis
Log into Travis with travis login --auto (from inside of your project respository directory), for Travis Pro use command travis login --pro.
Encrypt your S3 credentials using command travis encrypt AWS_S3_KEY="" AWS_S3_SECRET="" --add (be sure you add your actual credentials inside the double quotes)
In your .travis.yml file something like this will be added :
When you first start testing on Travis-CI you will see the next:
But for the next testing you will see the similar image:
Command “bundle install” will work very fast, because all needed gems are already present in “~/.bundle” folder. For my project testing speed was faster for 5 minutes (the duration of testing was decreased from 13 to 8 minutes).
Loading database scheme without rake command
When you run rake db:create db:migrate, command is load the Rails environment, which of course is not so fast. You can load your database scheme much faster by using built-in database tools (mysql, psql). Set in “config/application.rb” for your rails project:
In this case you rails app database scheme will be stored in sql format. Next, you should add such commands in “.travis.yml” file (example for PostgreSQL):
In you project file “database.travis.yml” should exist, which contains “DB_NAME”. For my project testing speed was faster for 1 minutes (the duration of testing decreased from 8 to 7 minutes).
Parallelizing your builds across virtual machines
To speed up a test suite, you can split it to the several parts using Travis-CI build matrix feature. Say you want to split up your unit tests and your integration tests into two different build jobs. They’ll run in parallel and fully utilize the available build capacity for your account.
Here’s an example on how to utilize this feature in your .travis.yml:
Travis will determine the build matrix based on the environment variables and schedule two builds to run.
Depending on the size and complexity of your test suite you can split it up even further. You could separate different concerns for the integration tests into different subfolders and run them in separate stages of the matrix building.
Paralellizing your build on one VM
Travis CI VMs run on 1.5 virtual cores. This is not exactly a concurrency, which allows to parallelize a lot, but it can give a nice speedup depending on case you use. Parallelizing the test suite on one VM depends on the language and test runner, which you use, so you will have to research your options. For Ruby and RSpec you can use parallel_tests gem.
This article describes some techniques for speeding up the testing of your Ruby project at Travis-CI. Of course others techniques can be exist which I did not mention, but these ones helped to reduce the testing time of the projects in several times.
That’s all folks! Thank you for reading till the end.