Crystal and Perl 6 join Travis CI

Hiro Asari's Gravatar Hiro Asari,

Today, we are excited to announce our newest members of our community-supported languages, Crystal and Perl 6!


Crystal is a programming language that focuses on developer productivity, type safety, and execution performance. It is statically checked and compiles to native (machine) code. It combines global type inference, compile-time macros, compile-time type introspection, automatic union types, and Ruby-like syntax, allowing quick prototyping and generating efficient computer programs. It provides a Garbage Collector, uses LLVM as its backend, and doesn’t run on a Virtual Machine.

Support for Crystal is provided by Ary Borenszweig, Jonne Haß, Juan Wajnerman, and Will Leinweber.

Perl 6

Camelia, the Perl 6 bug

Perl 6 is the next generation in the family of Perl programming languages, and a sister language to the well-established Perl 5. With a release candidate expected in September, and the first release by December, it's a great time to start testing your Perl 6 programs.

The Perl 6 support is provided by Paul Cochrane, Rob Hoelz, Nick Logan, and Tony O'Dell.

More detailed documentation is available for Crystal and Perl 6.

Happy Testing!

Travis CI Team

Storage Strategies and Continuous Integration

Benjamin Kisliuk,

This is a guest blog post by Benjamin Kisliuk.

ViOLa, which stands for the German title "Visualisierung und Optimierung von Lagerstrategien" (Visualization and Optimization of Storage Strategies), is a project group formed by eight master's degree students of the University of Osnabrueck, a city in the north-west of Germany.

Its goal was to implement a toolbox for examining various strategies for how to organize a storage most efficiently. Algorithms should be based on current research and examined for further improvement. Supervised by Sigrid Knust, the professor for Combinatorial Optimization, and two of her research fellows (Florian Bruns and Jana Lehnfeld), the project started in April of 2014 and is due to end after one year of sorting and organizing storages at the end of March 2015.

First Projects and the Quality of Code

Nine months ago I would not have thought how quickly thousands of lines of code, tests and documentation would pile up. For most of us this was the first software project going on for more than a few weeks and it is fair to say that it also was the first "real" application of all the teachings of code quality, testing and planning we received so plentiful during our years at the university.

Most of us already knew the blessings of code version tools so the decision to make use of git with Github as the central platform to host our software fell quite easy.

But whereas git is a good tool for working in parallel on different areas of a software, probably every developer around the world is familiar with endless hours and nerves spent on rerolling faulty commits, merging conflicting branches and swearing over unit tests once nicely implemented but forgotten to use before putting up a pull request.

Being able to work simultaneously on different branches of the same software is a great thing, integrating those branches is not. Even when using a powerful build tool as we did with using Gradle to build and test our code, mistakes are going to be made. Of course, all of this can be avoided by "just" being very professional, but having an automated process watching one's back could make a lot of things a whole lot easier.

After all, software development is all about automatization, is it not?

This is where the idea of continuous integration comes into play. It is hard to guess how many hours we have saved by the nasty red button telling us to have one more look at the changes we were going to merge, but letting Travis CI check on our pull requests right before merging them reduced to just two the number of times we had to rework our master branch since the project started.

So what do we let it do specifically?

As mentioned, we use Gradle to build our software and execute the tests, so when committing something new to GitHub, a Gradle build and test execution is started. Included here are plugins for Jacoco, having a look on our code coverage and SonarQube, which examines the code for common flaws and quality issues.

Worthy to note is, that our software - while mainly working within the Java machine - in part relies on Zimpl and SCIP to generate and solve problems formulated as ilp and mip - so the Travis VM also has to install them to be able to run the according tests. It also generates our Javadoc and tells us if there is something wrong. Although we were missing native a support for LaTeX documents we worked around that by having Travis download the required packages so that even our documentation is checked for errors before any merges. Obviously, the Travis cache comes pretty handy in reducing the times all these downloads and installations have to be made. In the end, Travis enables us to automatically use all these little helpers improving and ensuring our code's quality.

At the End of the Day

After nine months, what is left to say?

Getting work done means using the right tools and the ones we used in our project certainly were very right. The results we achieved in our research, visible in our implementation, would not have been possible to the extent reached today without Travis.

Software development is all about building stuff. Having to unravel histories of changes to find and fix a certain mistake which probably could have been avoided beforehand can be a pain.

This is why we want to close with thanking you, the Travis CI team, for supporting our work!

Introducing Travis Build Site, Our Public Roadmap and Changelog

Mathias Meyer's Gravatar Mathias Meyer,

Openness is one of our core values at Travis CI, and we strive to improve on being more open and transparent wherever we can.

A lot of our development happens out in the open, and you're more than welcome to follow along. But what's been missing is a clear picture of what we're working on at this very moment, what we've planned for the near future, and generally getting a better overview of our product roadmap.

While there's a lot happening in our GitHub issue tracker, getting a clear picture of what we're currently focused on isn't easy.

Today we're changing that by introducing our new Travis Build Site, our public roadmap of things we're working on right now, things that we've shipped and what we have in the pipeline for the near future.

We will keep this site updated, and we'll add more details in the near future to make it easier to follow along.

Have a look at the site, and let us know what you think!