When a lot of people are working on a product, it can get pretty painful when developers contribute to the end code. They have to manually coordinate and communicate all the changes, and this coordination goes far beyond the development teams, as it’s not only developers who are responsible for a product’s features. For instance, product teams must plan a sequential launch of features and choose people to be in charge of that. But the bigger the team, the higher the chances of failure in the code.

To relieve developers and other team members from all this work, continuous integration (CI) was invented. Basically, CI is the practice of regularly merging all working copies of a code to a shared mainline, multiple times a day. The CI collects all the code changes in one place, prepares their publication, and tests and prepares the code release. All this helps minimize human error in code review (which grows as the team grows), saves time, and improves the quality of the code.

Table of Contents

Continuous Integration, Continuous Deployment & Continuous Delivery: What’s the difference?

However, continuous integration is just the first step to continuous delivery and continuous deployment. You can hear about all of these when talking about modern development practices.

Continuous integration is a discipline that helps individual software developers combine parts of their code into the main code branch without breaking the combined code. CI runs automated tests so bugs won’t slip into the code and makes sure the application doesn’t break whenever new commits are integrated into the mainline.

Both continuous delivery and continuous deployment are what happens when the changes have gone through all stages of the development pipeline and are ready to be released. A pipeline is, in essence, the practice of organizing the development process. Usually, it’s broken down into stages so developers can get quick feedback.

Continuous delivery is one way to release the changes. CI makes sure that all code changes are collected regularly in an automated way. Meanwhile, continuous delivery is the practice that allows teams to release new changes from the source code repository to your end customers. With continuous delivery, this process gets streamlined and automated – just click the button whenever you’re ready to deploy.

Basically, you can choose the rhythm that suits your business needs and release daily, weekly, monthly, etc. Our tip would be to release as early as possible. This way, if there’s a problem with the code, small batches are easier to fix than larger changes.

Continuous deployment is a more sophisticated and fully automatic version of continuous delivery. After going through all of the stages of the production pipeline, changes can be released to your customers through automated releases. Again, this removes the risk of human error, and only a failed test can prevent a change from going through.

Automated releases allow the development team to focus on their work and forget about the pressure of the so-called Release Day. Besides, they can get user feedback a lot faster and see the results of their work within minutes of finishing it.

To put it simply, continuous integration lays the ground for continuous deployment and continuous delivery. These two are similar – they both help release changes, but unlike continuous delivery, continuous deployment releases happen automatically.

All and any releases, regardless of which one of the CDs you choose, follow a certain release workflow. Usually, the release workflow is broken down into phases:

Plan – recording of initial details, defining release package, schedule and release plans, assigning tasks to team members;

Build – creating one or more release packages;

Test – testing the release build in a mock environment;

Document – creating release notes;

Approve – approving deployment of the release to a live environment;

Deploy – deployment of the release to a live environment;

Review – recording final details, closing the release.

Using CI/CD: Why and When?

Like most pleasures in this world, using CI or CD costs something, but their benefits will make you forget your losses.

With CI, your development team will have to create automated tests for all new features, as well as improvements or bug fixes. You will need a continuous integration server (or a cloud service, which should be cheaper), while your developers will have to merge their changes as often as possible.

What you get, though, is:

Much fewer bugs making their way to production, as they’re being caught early by automated tests.

Any and all integration issues will be solved at an early stage, which means that building the release is now easy as pie.

Thanks to early alerts, developers can fix the build before they move to other tasks.

Tens or even hundreds of tests within seconds, which reduces testing costs substantially. Also, now your QAs can also focus on more pressing issues and spend less time testing bugs.

To use continuous delivery, you’ll need a strong CI base, and your codebase should be sufficiently covered by your test suite. The deployment trigger with continuous delivery is manual, but the deployment itself should be automated. Once it’s started, there won’t be any need to involve people. Also, your team will have to use feature toggles to hide, enable or disable certain features during run time to not affect customers while in production.

Here’s the list of the benefits you get:

The pressure of the Release Day is gone – deploying software isn’t as complicated anymore;

Which also means: more releases and a faster feedback loop;

Faster iterations, as there’s much less pressure when deciding about small changes.

And finally, for continuous deployment, the quality of your test suite should be top-notch. The quality of your releases will depend on it. Next, the documentation process should go neck-to-neck with the deployments. Again, you’ll have to use feature toggles for significant changes to be able to coordinate with other company departments.

What you win, however, is:

Faster development, thanks to automatically triggered pipelines – there’s no need to pause for releases!

Less risk and easier fixes due to smaller batches of changes being released.

Happier customers – they get continuous improvements, instead of monthly or yearly updates.

What kind of companies are using CI, which teams benefit, and how?

Just to give you an idea of how widely CI is used, look at this list of the world’s largest companies that profit from it:

Amazon could decrease the number of simultaneous outages and increase revenue by releasing code every 11.7 seconds on average. Netflix isn’t as fast – their developers release code only several times a day, yet still they manage to adjust to their customer’s needs. Facebook’s quick development lifecycle allows them to follow and change their customers’ expectations, while releasing the product every two weeks.

While development benefits are pretty much on the surface, what are the business benefits of CI and CD?

Velocity. Faster development allows your company to respond faster to market changes, and thus, outrun the competition. No one needs a feature that was required 6 months ago. Besides, the sooner you find a bug, the sooner and cheaper you can fix it. However, always remember to keep high quality standards. Without quality, speed won’t get you far.

Productivity. Filling out bug reports has never made anyone happy. And unhappy developers are less productive and less engaged. You don’t want that for your team. Let machines deal with bugs and defects, while your team does what really matters. Let your team be productive and happy.

Sustainability. Every business wants their team to be on top of their game. To avoid early burnout, you can delegate repetitive work to machines and reduce the manual labor. This will also save you money, as people require more expenses than tools.

Besides, CD provides flexibility. Features can be released to certain groups and subgroups of customers, enabled, disabled, tested or left dormant.

How CI Works

As we’ve already established, CI is the process in the software development cycle where all the code changes and features from different team members are integrated. You can say it’s a smart pot that makes sure all the ingredients are correct and cooks them into something delicious.

In the past, team members would work on their assigned parts of the product to bring them together at once. Obviously, this caused the development process to be extremely long and painful. Over time, there was a need for frequent integration – usually, right after a unit was complete, all changes were integrated into a shared source-code repository. With integration becoming automated and continuous, a dire need for testing arose to make sure only the correct code and features made it into production. Thus, continuous integration was introduced.

Usually, the CI process depends on the project, the tools and programming language the team uses, along with some other individual factors. But there’s still a common workflow that consists of phases like committing code to the code repository, static analysis to find possible bugs (with no need to run the software), pre-deployment testing, packaging and deployment to the test environment, and post-deployment testing. Here’s a visualization that will help you understand the process:

How to Choose Continuous Integration Tools

Depending on the size of your company, your product, goals and philosophy, there are many CI tools to choose from. Feel free to go online for reviews and tips to compare the tools at hand. But beware – if you use resources like Stackshare, keep in mind that reviews placed there are mostly extremely subjective and not entirely reliable. On top of that, what you read there may not be up to date – and you don’t want your decision to be based on outdated information. In any case, avoid basing an important decision like this on criteria like these:

GitHub integration. (Most CI tools offer this by default.)

Availability of a free plan for open-source code. (All cloud services offer this.

“Easy to set up” testimonials. (‘Easy to set up’ and ‘easy to run’ are different things and depend on team expertise and size.

Trendy companies using a particular tool. (Companies have many teams. Even if someone tested a tool and no longer does, it’s advertised out of proportion. Thus, better look for cases of specific teams and specific uses.

Integrations with other software. (Usually, this doesn’t make much sense as integrations are sometimes as easy as a line of code.)

We recommend that you rate tools according to the following criteria, which will definitely help you make up your mind:

Whether the code is Open Source

Compatibility with build environments and languages

Availability of hosted and cloud-based options

Compatibility with version control system (VSC) providers

Testing integration details

Ease of configuration/setup

Administration cost/learning curve

Free plan possibilities (suitability for testing the product)

Paid plan features (minutes, users, repos)

Based on these features, there are two types of tool we’d like to cover: Leaders and Alternatives.

The Leaders: CircleCI vs Travis CI vs Jenkins

Of course, there is no silver bullet when it comes to choosing a CI solution. Your choice will depend on the size of your team, programming language, and something as simple as personal preferences. Which is why it’s important to compare the characteristics of every tool based on the criteria mentioned above.

However, some tools have earned themselves a Leader’s position in the market. These Leaders are CircleCI, Travis CI and Jenkins.

CircleCI

CircleCI is a cloud-based tool for continuous integration and deployment. Using unit tests, integration tests and functional tests, it’s deeply focused on testing all code changes submitted. Leading companies like Facebook, Kickstarter, Spotify, Lyft, Coinbase, Expedia, Stitch Fix, and Dollar Shave Club have been running their development process successfully on CircleCI. This way, they managed to accelerate delivery and improve product quality.

Founded in 2011 and based in San Francisco, CircleCI was named a Leader in Continuous Integration by Forrester in 2017. Venture-baked and supported by remote teams worldwide, CircleCI is staying true to their motto by helping companies ship quality code fast.

This tool is a pretty good option for testing the waters of continuous integration, especially for projects that use containerization (Docker), and offers the following features:

Private code base with some open source “orbs”; shareable configuration packages for builds

Supports all languages that build in Linux or iOS build environments

Offers both a private server and hosted cloud options

VCS: Supports projects using Bitbucket, GitHub in the cloud plan; GitHub and GitHub Enterprise in the server plan

Workflows and automated testing on virtual machines

Quality documentation of lightweight yml configuration settings, fast set-up for projects

An out-of-the-box cloud solution that’s relatively easy to maintain once set up

Opportunities to…

1,000 build minutes per month and unlimited repos in a free plan – great for trying out continuous integration

Scalable paid plans include unlimited repos, users and minutes — simplifying the selection criteria to the number of containers and concurrent jobs.

TravisCI

Travis CI is a tool created for open-source projects and focused on CI. It uses automated testing and an elaborate alert system to improve the build process. You can quickly test your code – Travis will supervise all changes and let you know if the change was successful or not. Like CircleCI, Travis CI is great for making your first steps in continuous integration out-of-the-box solutions. However, Travis CI doesn’t have a free plan for a private repository – plans start at $69/month.

Based in Berlin, it’s not VC-funded, and more of a community of developers that encourages diversity, sharing, and sustainability.

Unlike CircleCI, Travis CI does support the build matrix – a tool that provides an opportunity to run tests with different versions of languages and packages. You can customize it the way you want. For example, fails of some environments can trigger notifications, but don’t fail the entire build (which is helpful for development versions of packages).

Travis CI features include:

Many parts of the software are free on GitHub, with some private code written in Ruby

Support for all languages that build using Linux, macOS and — most importantly — Windows

Both a private server and hosted cloud options

VCS is GitHub

Testing that can be done on library or applications against multiple runtimes and data stores without having them installed locally over multiple operating systems

Well-documented lightweight yml configuration settings; quick set-up of projects thanks to preinstalled data bases and services

An out-of-the-box cloud solution that’s relatively easy to maintain once set up

No free plan (only a free trial for 2 concurrent jobs and 100 first builds)

Jenkins

Jenkins is the leading open-source continuous integration tool. Over 300 plugins to support building and testing of literally every project make it flexible to the tiniest detail. The tool is free to use, but the learning curve is steep to set up and run compared to other boxed solutions. This makes Jenkins the best fit for teams in large companies where a dedicated DevOps Engineer can support and administer the environment. This isn’t trivial, because the Jenkins support engineer would have to be proficient in the Groovy programming language.

Jenkins has the following features:

A fully open-source code base, written in Java

Supports all major languages

Runs on your own private server or a 3rd-party cloud hosting option

In theory, compatible with any type of version control system

Powerful Pipeline syntaxis generating script that helps automate many processes, including testing

Configuration via Jenkinsfile; can be customized to the smallest detail, but it’s probably one of the most complex processes, but thankfully now a little easier with the help of pipeline scripts

Most customizable in terms of

All Jenkins components are free to use, but don’t underestimate the time and cost for the DevOps engineer to customize, configure, and run the environment.

Before we touch on the alternative CI tools, let’s sum up what we know about the Leaders:



CircleCI TravisCI Jenkins Software model Mostly private (some open source) Some private (some open source) Open source Supported OS Linux or MacOS Linux

macOS

Windows All (no limitations) Source Code Repositories GitHub

Bitbucket GitHub All (no limitations) Cloud solution yes yes yes Configuration yml file yml file Jenkinsfile Custom cloud / private server solution Yes (including a free plan) Yes (no free version) Custom cloud / private server solution Paid plan details Based on containers and concurrent jobs (unlimited hours, users, minutes) Based on concurrent jobs (unlimited hours, users, minutes) Free to use, requires a dedicated administrator Edit

Notable Alternatives: GitLab vs TeamCity vs Drone

The truth is, there are numerous alternatives to the Leaders; however, they don’t have such a large variety of features, and their documentation is weaker as well. Let’s see what the main contenders to the leading CI solutions have to offer.

GitLab

GitLab have developed their own CI tool, but to be perfectly honest, it only makes sense for projects using other GitLab tools.

The GitLabCI tool supports all major languages and uses a relatively light yml file configuration. However, it also:

Offers mostly open-source add-ons to GitLab software development tools written using Ruby, Go and Vue.js

Was built for use with GitLab repositories

Can be used for free when there is a DevOps engineer managing customization and configuration.

TeamCity

TeamCity is a free tool that is a great choice for those who want more control and more security for their code. This tool uses templates, project hierarchy, and extensive reporting to help keep code clean.

Here’s a list of features to give you a better idea of TeamCity:

Private code base written in Java

Supports all languages

Offers both a private server and hosted cloud options

VCS: Supports projects using Bitbucket and GitHub

Heavy emphasis on quality of testing and testing metadata

Lightweight yml configuration settings are well documented

An out-of-the-box cloud solution that’s relatively easy to maintain once set up

Unlimited build configurations for 60 days to try continuous integration

Steeply priced paid plans include unlimited repos, users and minutes, based on the number of agents.

Drone

This one’s a new CI tool optimal for containerized projects, modern and fast, built using Go. Drone is perfect for teams trying continuous integration on projects that use containerization, such as Docker.

How does Drone work? Here’s a list of features:

Private code base written using Go

Supports all languages

Offers both a private server and hosted cloud options with many presets

Supports projects using Bitbucket, GitHub

Workflows and automated testing on virtual machines

Lightweight yml configuration, projects can be set up fast

An out-of-the-box solution that’s easy to launch via Docker; easy to maintain once set up

Free plan only limits builds to 5,000 per year

Paid plans are based on the number of users and support (community or enterprise).

Notable CI Alternatives



GitLab TeamCity Drone Software model Open source Mostly private Mostly private Supported OS All (no limitations) All (no limitations) All (no limitations) Source Code Repositories GitHub GitHub Source Code Repositories Bitbucket All (no limitations) Bitbucket All (no limitations) Cloud solution yes yes yes Configuration yml file yml file yml file Custom cloud / private server solution Yes (requires an administrator to set up and run) Yes Yes Paid plan details If chosen (still requires an administrator to set up and run) Based on agents (unlimited hours, users, minutes) Pricing based on users and support. Cloud plan based on cloud use of Packet Edit

Get started with CI

As I said at the very beginning, with large teams it may get chaotic when it’s time to integrate code changes and new features. In order to avoid human error and distraction, it’s always better to automate this process with continuous integration. By now, you should now have a good idea of the concepts behind CI and its most common tools. In conclusion, here are a couple of tips that will help you choose the CI tool that’s best for your needs: