Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Continuous Integration - Know your opportunities

Continuous Integration in a nutshell

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: since this post is mostly related to tools you may find out there, if you want to know more about Continuous Integration we warmly suggest you the reading of this blog post by Martin Fowler and of Paul Duvall's book Continuous Integration in order to fully understand what are the benefits of this practice, and which are the underlying values and principles.

CIs: In-House and Hosted

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 may want to clarify consists in understanding either 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 (formerly known as Hudson) widely recognized as the de-facto standard solution. Nowadays Jenkis probably still remains one of best solutions one may adopt when setting up an In-House CI pipeline mostly due to its being battle-tested during the years, its wide community and the large set of plugins available.

alt text

The major benefit we can experience by adopting this kind of solution consists in the "total" control we can have over the CI environment: since we are the owner of the installation we have the freeedom to install any specific compiler, VM or service needed, unistall, upgrade or downgrade it. Moreover 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 during the setup phase 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 configuration 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.

alt text

Travis has several advantages: it 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) and 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 and 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 the concept of 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.

alt text

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 is another Continuous Integration platform built on Docker and can be used both as Hosted or In-House solution. 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.

alt text

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:

  1. install Docker
  2. install drone
  3. configure your drone and your GitHub project so that they can interact
  4. 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:

Final Thoughts

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.


This comment has been minimized.

Copy link

tprus commented Sep 13, 2016

I don't like searching how to do something, how to configure it - so even, i liked Jenkins a lot i switched to

Some 2 minute video

Great UX, simple but powerful tool, many integrations, full automation, new modern way (pipelines), hosted and Docker-based free standalone version...


This comment has been minimized.

Copy link

DrRibosome commented Sep 18, 2016

should really include gitlab ci as well - it's come a long way and it's pretty easy to set up self hosted runners too


This comment has been minimized.

Copy link

bolorundurowb commented Jun 27, 2017

@tprus it seems like buddy is basically herding us to use the UI. I tried configuring my pipelines using the buddy.yml file and when I wanted to add mongodb support, there was nothing in the documentation about that, now I'm stuck.


This comment has been minimized.

Copy link

hmaurer commented Jul 14, 2017

@bolorundurowb a bit hacky but you can configure mongodb on a new project using the UI then click on the "yaml config" link; it will generate a yaml config from your current settings (with the mongodb integration I assume).


This comment has been minimized.

Copy link

kellyjandrews commented Jul 29, 2017

While I am the Codeship developer advocate, I would recommend Codeship to anyone even if I were not. Easy to use, super powerful, and very extensible.


This comment has been minimized.

Copy link

loudaTW commented Jul 31, 2017

I wanted to mention that Snap CI is EOL'd as of August 1st. It's also worth mentioning GoCD (on-prem) as well. (disclaimer: I work at ThoughtWorks)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.