Continuous Integration (CI) is an important practice every team should adopt in order to detect defects and errors early and solve integration problems easily. Roughly speaking we may say that CI is a practice that allows the growth of solid software by giving greater confidence to the developers and better products to the final customers.
The concept behind CI is fairly simple: the codebase is owned by several developers that continuously integrate their changes to a common version control system. For each integration the system runs a predefined set of tasks automatically; these tasks may vary from running all the tests to building all the components.
When it comes to setting up a CI pipeline for our projects we have many different solutions available and each one has its pros and cons. In XPeppers we strongly believe in the value added by Continuous Integration to our projects and therefore in this blog post we'll try to give the reader an overview on some CIs platforms based on our past and current experiences; hopefully this will be helpful to the reader who wants to pick the right tool for her needs.
Nevertheless, don't ever forget that Continuous Integration is an attitude, not a tool. In order to fully understand what are the benefits of this practice, and which are the underlying values and principles, we warmly suggest you the reading of this blog post by Martin Fowler and of Paul Duvall's book Continuous Integration.
If you are new to the world of Continuous Integration but you want to integrate it to your next project, one of the first things you should decide is whether you need to setup your own In-House CI server or to use one of the services available online.
In the past, the former option was largely the most adopted with Jenkins (previously known as Hudson.
Nowadays Jenkis probably still remains one of best solutions one may adopt when setting up an In-House CI pipeline. This is mostly due to its being battle-tested during the years, its wide community and the large set of plugins available.
The major benefit we can experience by adopting this kind of solution is that we have full controll over the whole build pipeline and we are free to install any specific compiler, VM or service needed.
Another benefit is that we are less affected by network issues since our CI environment will be installed on a dedicated machine (most likely a virtual one) reachable through the local network or hosted in our personal AWS instance, therefore we don't have to worry about some external system failures or network issues (or at least we can control them safely and schedule the downtime interval).
On the other hand, the "In-House approach" may be tricky to setup because we have to do everything by ourselves, and this means that we have to take care of the machine setup and maintenance, installing the proper version of the language, all the needed plugins and their configurations... this may require time, a lot of knowledge, effort, dedication and a discreet amount of patience.
If we don't want to deal with these system configurations we may take a look at Travis.
Travis is what we call an Hosted (or "as a service") CI, meaning that we are no more in charge of setting up all the needed dependencies; we just go to the Travis website, sign in with our GitHub account (Bitbucket is not supported), link our public github repository and commit a simple YML config file in the root of our project. By taking these few steps we can set up a complete fully working CI environment in a couple of minutes.
Travis has several advantages:
- is free for an unlimited number of public repositories and collaborators
- supports a great variety of programming languages (e.g., JavaScript with Node.js, PHP, Python, Erlang, Ruby, Java, Scala, Clojure, Groovy, Objective-C and Perl)
- integrates out of the box with many famous datastores (e.g., MySQL, PostgreSQL, Riak, MongoDB, Redis, ElasticSearch ...) and services (e.g., RabbitMQ, Kestrel, Memcached ...) just to cite some
What are the main issues one may face when using Travis? There are not real issues or big reason to complain about it, the service is easy to use and really well maintained, probably the perfect solution for public projects on GitHub.
It should be noticed though that:
- with a free plan we can't connect private repositories
- we don't have full control over the post-build steps (e.g. where to deploy our build artifacts)
- we don't have control on the priority in the build pipeline
A different service that can be considered as a valid alternative to Travis is Shippable, the new kid in town of the CI as a service world.
Shippable provides a YML interface very similar to the Travis's one, and therefore is really easy to setup a CI for your needs. Since Shippable is based on Docker Containers, it proves to be very fast and having used it as a "backup CI" in one of our recent project we observed that it was much faster than its competitor, we really appreciated this.
Shippable has a free plan that allows an unlimited number of free repositories and up to 5 private repositories (with support also for Bitbucket) but is not as mature as Travis is: it does not support the same wide range of languages (php has only recently been added) and services, and sometimes it behaves in an unexpected way, but the people at Shippable are prompt to receive feedback from their customers and add new stuff often and fast.
The last CI solution we will explore in this post is Drone.io.
Drone.io is another Continuous Integration platform built on Docker and can be used both as Hosted or In-House solution with their open-source project. Used as an Hosted solution, drone is very similar to Travis and Shippable (simplicity achieved by its YML configuration and different pricing plans available), but when used as In-House platform drone proves to be very easy to install and configure.
If you decide to use drone as your In-House platform, these are the steps you need to follow in order to obtain a working installation:
- install Docker
- install drone
- configure your drone and your GitHub project so that they can interact
- configure your local .drone.yml file
If you want a deeper insight on how to build and configure your drone/docker environment locally you can take a look at our gist or to this online guide by Jean-Philippe Boily.
We don't suggest Drone only for its being new and for its nice features, in fact for us at XPeppers was also a great way to start scraping the surface of the world that gravitates around Go and Docker gradually.
Many other solutions are available out there! Here's a list of different CI platforms (in not any particular order) the reader may want to try out:
In this post we briefly introduced the concept of Continuous Integration and gave an insight to the two most common approaches used: In-House and Hosted. We explained the difference between these two solutions and discussed both explaining what are the pros and the cons one may encounter by picking one over the other. For what concerns the In-House solution we suggested the use of Jenkins or Drone, while for the Hosted solutions we discussed the most popular platforms available out there giving a little overview for each one.
Hopefully, reading this article you undestood (if you didn't know before) what Continuous Integration means and which CI platform best fits your needs.
Filippo says: "Molto chiaro, magari aggiungerei una mini recensione per ogni servizio
hosted menzionato e un confronto con pro e contro tra hosted e gestito
in casa."