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.
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 speking 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.
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.
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.
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. 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:
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.
---> scollega drone e collega links e conclusione <---
Many other solutions are available out there! Here 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 discussed both solutions explaining what are the pros and the cons we may encounter by picking one over the other. For the In-House solution we proposed you the use of Jenkins or Drone, while for the Hosted solutions we discussed some of the several platforms available out there.
---> Expand conclusion <---