Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
You’re doing continuous delivery when:
- Your software is deployable throughout its life-cycle
- Your team prioritizes keeping the software deployable over working on new features
- Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
- You can perform push-button deployments of any version of the software to any environment on demand
Lets start with the defnitions
Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day.
Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do Continuous Deployment you must be doing Continuous Delivery.
Continuous Integration usually refers to integrating, building, and testing code within the development environment. Continuous Delivery builds on this, dealing with the final stages required for production deployment.
Each of the points above depend on those below. In order to do Continuous Deployment, one must be able to continuously integrate and deliver.
In order to successfully and efficiently implement Continuous Delivery, new tools need to be adopted. That adoption should be followed by a change in development procedures and workflow.
Some of the commonly used CI tools are Jenkins, Hudson, Travis and Bamboo. Basic principle behind all of them is the detection of changes in the code repository and triggering a set of jobs or tasks.
Jenkins
Jenkins is an open source continuous integration tool written in Java. The project was forked from Hudson after a dispute with Oracle.
Jenkins provides continuous integration services for software development. It is a server-based system running in a servlet container such as Apache Tomcat. It supports SCM tools including AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase and RTC, and can execute Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and Windows batch commands. The primary developer of Jenkins is Kohsuke Kawaguchi.
The basic functionality of Jenkins is to execute a predefined list of steps based on a certain trigger.
The trigger might for example be an change in a version control system or a time based trigger, e.g., a build every 20 minutes.
The list of steps can for example include:
perform a software build with Apache Maven or Gradle
Run a shell script
Archive the build result
Afterwards start the integration tests
This is the most widely used tool in the market.
Bamboo
Bamboo is the product of Atlassian. When compared to Jenkins, Bamboo is sexy. It is easier to use and it looks better. Usability is one of the first differences one would notice. Moreover, it is well-integrated with the rest of Atlassian’s products (JIRA, Confluence, BitBucket, etc).
Major downsides are its price and extensibility. It is the only tool listed in this article that is not free. If one needs to perform some non-common task, it is much more likely that plugin exists only for Jenkins. Same applies to help. Even though Atlassian provides great support, it is not so easy to find other users to talk to or ask for help.
If ease of use or integration with Atlassian products is priority and licensing price is not an obstacle, Bamboo is a great choice.
Travis
Main strength of Travis is that it is simple. Unlike Jenkins that allows almost unlimited plugins, creation of innumerable jobs, complicated flows, etc, Travis is based on a single file .travis.ylm that resides in the root of your code. Even though contents of that file can become complicated, in most cases Travis assumes that we’re following certain standards. Use of standards and simplicity is what often leads to a better and more efficient design.
Travis most of the time knows what should be done without any need to explicitly define the flow. For example, if there is the build.gradle file, Travis will understand that it should be compiled, tested, etc. using Gradle. It inspects your code and acts accordingly. One can switch from Ant to Maven to Gradle without making any changes to Travis or the configuration file.
Travis has a strong dependency with GIT. In cases when some other version controls system is used, Travis is not a good option. If, on the other hand, you are using GIT, working with Travis is like forgetting that CI even exists. Whenever the code is pushed to the repo Travis will detect it and act depending on changes in the code (including .travis.ylm). If there is a problem, you will be notified by email. All CI tools, when setup correctly, should work like that. Kind reminder when there is a problem, oblivion when there is none. Travis, brings this to the next level by, in most cases, removing the need to deal with jobs, configurations and other nuances.
Keeping CI configuration (.travis.ylm) as integral part of the code brings advantages. Through that config, you tell it what to do and he does it.
Simplicity comes at a cost. When complicated, non-standard, nobody-heard-of-it-before type of things are needed, Travis tends to be difficult to fight with.
Tools Summary
These are the four solutions come to my mind whenever I think of Continous Integration implementation.
