There are many benefits in using Continuous Integration tools like Travis CI as they improve the confidence developers have in their code and pull requests. This post will help you evaluate Travis CI and other Continuous Integration and Continuous Delivery platforms to show which tools can be used in differing use cases.
When creating a build with Travis CI, it clones your GitHub repository into a new virtual environment and performs a series of tasks that are laid out in the .travis.yml file to build and test the code. Travis can only run builds on the commits that are made after a .travis.yml file is added. Below shows a standard Travis CI setup. As more build capacity is needed, more workers can be added.
Travis CI stands out for its automated testing and notification system that alerts the user to improve the build process. It supports a tool, called the build matrix, that provides an opportunity to run tests with different versions of languages and packages. This allows for more and better customization.
When evaluating tools, you must weigh the pros and cons of each and look at them with an unbiased attitude to see which is the most fitting for your solution. Not only that, but you also need to think long-term - what features will you most likely need one, maybe two years down the line? Will the tools you are evaluating support these features/needs? The sections below about the different alternatives to Travis CI will highlight the key features and capabilities that make that particular CI tool unique and help organizations be successful in software delivery. To find a more exhaustive list of different DevOps solutions that may be ideal for your needs, check out our buyer’s guide to CI/CD!
GitLab, originally a source code management tool based on Git (like GitHub and Bitbucket, for reference), introduced a CI/CD solution to their product suite. They support all major cloud providers, including Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). They also support container orchestration tools, such as Kubernetes and ECS. In terms of infrastructure, GitLab recently released a Terraform integration.
A major incentive to use GitLab is the ease and basically built in functionality. Everything can be in one place. A single application can take care of the entire DevOps lifecycle from source control management to release and monitoring. Only one application is needed for integration and permissions. Within GitLab, it provides you with deeper insights such as programming languages used in the repository, code coverage history and number of commits per month, day and hour. This allows users to have visibility and a more thorough understanding of the CI/CD process.
The CI/CD platform also offers good governance and compliance features available on their enterprise-level plans. GitLab has a beautiful user interface, but where it lacks is its ease of use. There is definitely a learning curve to utilize the platform.
As far as Travis CI alternatives go, GitLab is a fairly good recommendation, especially if GitLab is already your source code manager of choice.
CircleCI is regarded highly within the industry as it helps developers push successful green builds safely and securely. The tool focuses on testing all code changes submitted and has been used by many well-known companies. Like Travis CI, build configurations live in a file that must be added for the pipeline to run. Having these configuration files, and having them live in source control management, allows developers to change builds on a per branch basis.
Each build run in CircleCI runs in a clean LXC container that can be directly SSHed into. This allows for quick and advanced debugging to find out why a pipeline failed. Also, in each build container, there are pre-installed packages that include the most popular databases, languages, and frameworks. This makes it easy as the containers are ready to go. If there are configuration elements that are not included, CircleCI has a resource called Orbs. This resource makes writing and customizing CircleCI’s config simple as they adhere to a Reusable Configuration feature that allows the developer to define parameterized configuration elements and reuse those elements throughout the project config file.
CircleCI can do a lot. You can use many different languages, frameworks, and dependencies in your build and there is even an API for custom integrations. It also provides built-in Docker support and iOS support. Even though it provides all of these features, it does currently lack security and governance, which more experienced users need - and the list of integrations and plugins that are built-in isn’t extensive.
Harness is a software delivery platform. Not only does it encompass Continuous Integration, it also includes Continuous Delivery, Cloud Cost Management, Deployment Verification, and soon Feature Flag Management. Aligning to CI and Harness’ offering for CI, we can take a look at Drone. Drone is a self service, completely open source tool that developers love.
Harness is devoted to the open source community and plans on keeping their enterprise pricing model consistent as well as keeping Drone fully open source. This past March, Harness released some new features in Drone 2.0. This update included a new look and feel which enhances the developer experience, as there are graphics to depict build time, charts, and a pipeline visualizer. Like Travis CI, Drone can be integrated with GitHub and Bitbucket, but also other source control management tools and it runs as a GitOps process. They also can both authenticate with GitHub, for example, but Drone offers a user management screen.
Drone is container-native so all builds are isolated and all extensions are standardized. It also has around 150 containerized plugins! This allows for easy customization and adds greater functionality to the tool. If a plugin a user is looking for doesn’t exist, he/she can create one and it can be as easy as writing a bash script. To make it usable by others, the user can add it to the Drone registry website by sending in a pull request. That is the power of open source.
Drone offers extensive support when building in a VM, Docker, K8s, or MacStadium. This support is manifested in the form of a runner. In Drone a runner polls the server for workloads to execute. These runners are optimized for different use cases and runtime environments and this is when Drone shines.
Jenkins is the most well-known open source, self managed, automation tool that is used for both Continuous Integration and Continuous Deployment. Since it is open source, it is free to use for all and there is a huge community following which leads to extra support, documentation, and features. Jenkins has over 1800 plugins available because of this community, which adds to the flexibility of the tool. The sheer number of plugins makes customization easy and gives Jenkins the ability to integrate with almost any tool necessary for development.
Like Travis CI and many of the other tools, Jenkins has a file that must be added in order for the pipeline to run. In this instance, it is called a Jenkinsfile. This file requires a lot of scripting, unlike Travis CI. There is a learning curve involved in creating a Jenkins pipeline as groovy syntax isn’t always the easiest to manipulate. Jenkins also lacks the GitOps feature as there is no centralized location to keep the Jenkinsfile for version control.
When it comes to installing, Jenkins is pretty easy. This CI tool is a self contained Java program that is platform agnostic. It is available for most major operating systems such as linux, windows and macos, and is also available as a normal installer and a war file.
While there is definitely a lot of good to Jenkins mostly due to the extensibility we mentioned above, the reality is it’s a ten year old tool that wasn’t built to be cloud native. And while yes, the extensibility is very good, having to rely on scripts and plugins isn’t a good thing in itself. For one, plugin authors often abandon their plugins (leaving you to scramble to find a new plugin or write your own), plugins can create dependency chains, plugins can introduce security vulnerabilities, etc. We don’t feel comfortable recommending a product that relies so heavily upon added extensibility.
When evaluating tools that are right for your solution, it’s important to look at all the options and alternatives to see which is the most fitting for your needs. Each CI tool has its own differentiating features that make it stand out to users. To evaluate even more providers not mentioned in this blog and see a more in-depth breakdown including feature comparisons, go to our DevOps Comparison Tools page.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.