Travis CI logo

Travis CI

A hosted continuous integration service for open source and private projects

What is Travis CI?

Free for open source projects, our CI environment provides multiple runtimes (e.g. Node.js or PHP versions), data stores and so on. Because of this, hosting your project on travis-ci.com means you can effortlessly test your library or applications against multiple runtimes and data stores without even having all of them installed locally.
Travis CI is a tool in the Continuous Integration category of a tech stack.

Who uses Travis CI?

Companies
929 companies reportedly use Travis CI in their tech stacks, including Lyft, N26, and Heroku.

Developers
4027 developers on StackShare have stated that they use Travis CI.

Travis CI Integrations

GitHub, Slack, MySQL, npm, and Amazon S3 are some of the popular tools that integrate with Travis CI. Here's a list of all 65 tools that integrate with Travis CI.

Why developers like Travis CI?

Here’s a list of reasons why companies and developers use Travis CI
Private Decisions at about Travis CI
Private to your company

Here are some stack decisions, common use cases and reviews by members of with Travis CI in their tech stack.

CircleCI
CircleCI
Travis CI
Travis CI

I initially chose CircleCI for a personal project because I was not satisified with using Travis CI in the past. When it came time to develop my CI/CD config on Circle, I was pleasantly surprised with the fantastic documentation, invaluable collection of example configs and helpful support provided. The free tier they provide is quite robust for most small projects and the platform is updated frequently with nice features.

Areas where CircleCI could improve:

  • the UI is a bit slow (you can feel the local machine straining to load all the code) and it is not as intuitive as it could be
  • many UI elements receive updates and/or changes that are not always reflected in the current docs
See more
Travis CI
Travis CI

To make sure that I don't push bugs to production. Travis CI

See more
Travis CI
Travis CI

CI via travis Travis CI

See more
Travis CI
Travis CI

Travis CI builds and tests every commit. It's also used to deploy Buildtime Trend as a Service to Heroku and the Buildtime Trend Python library to the PyPi repository. Travis CI

See more
Travis CI
Travis CI

Continuous integration Travis CI

See more
Travis CI
Travis CI

build server and deploy to heroku Travis CI

See more
Public Decisions about Travis CI

Here are some stack decisions, common use cases and reviews by companies and developers who chose Travis CI in their tech stack.

Tim Abbott
Tim Abbott
Founder at Zulip · | 14 upvotes · 98.9K views
atZulipZulip
Travis CI
Travis CI
CircleCI
CircleCI

We actually started out on Travis CI, but we've migrated our main builds to CircleCI, and it's been a huge improvement.

The reason it's been a huge improvement is that Travis CI has a fundamentally bad design for their images, where they start with a standard base Linux image containing tons of packages (several versions of postgres, every programming language environment, etc). This is potentially nice for the "get builds for a small project running quickly" use case, but it's a total disaster for a larger project that needs a decent number of dependencies and cares about the performance and reliability of their build.

This issue is exacerbated by their networking infrastructure being unreliable; we usually saw over 1% of builds failing due to transient networking errors in Travis CI, even after we added retries to the most frequently failing operations like apt update or pip install. And they never install Ubuntu's point release updates to their images. So doing an apt update, apt install, or especially apt upgrade would take forever. We ended up writing code to actually uninstall many of their base packages and pin the versions of hundreds of others to get a semi-fast, semi-reliable build. It was infuriating.

The CircleCI v2.0 system has the right design for a CI system: we can customize the base image to start with any expensive-to-install packages we need for our build, and we can update that image if and when we want to. The end result is that when migrating, we were able to delete all the hacky optimizations mentioned above, while still ending up with a 50% faster build latency. And we've also had 5-10x fewer issues with networking-related flakes, which means one doesn't have to constantly check whether a build failure is actually due to an issue with the code under test or "just another networking flake".

See more
Praveen Mooli
Praveen Mooli
Engineering Manager at Taylor and Francis · | 12 upvotes · 705.2K views
MongoDB Atlas
MongoDB Atlas
Java
Java
Spring Boot
Spring Boot
Node.js
Node.js
ExpressJS
ExpressJS
Python
Python
Flask
Flask
Amazon Kinesis
Amazon Kinesis
Amazon Kinesis Firehose
Amazon Kinesis Firehose
Amazon SNS
Amazon SNS
Amazon SQS
Amazon SQS
AWS Lambda
AWS Lambda
Angular 2
Angular 2
RxJS
RxJS
GitHub
GitHub
Travis CI
Travis CI
Terraform
Terraform
Docker
Docker
Serverless
Serverless
Amazon RDS
Amazon RDS
Amazon DynamoDB
Amazon DynamoDB
Amazon S3
Amazon S3
#Backend
#Microservices
#Eventsourcingframework
#Webapps
#Devops
#Data

We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.

To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas

To build #Webapps we decided to use Angular 2 with RxJS

#Devops - GitHub , Travis CI , Terraform , Docker , Serverless

See more
Jesus Dario Rivera Rubio
Jesus Dario Rivera Rubio
Telecomm Engineering at Netbeast · | 10 upvotes · 611.7K views
atNetbeastNetbeast
React Native
React Native
Android SDK
Android SDK
Objective-C
Objective-C
Travis CI
Travis CI
Bitrise
Bitrise
GitHub
GitHub
Firebase
Firebase
Amplitude
Amplitude
Intercom
Intercom
Mailjet
Mailjet
#SmartHome
#End2end

We are using React Native in #SmartHome to share the business logic between Android and iOS team and approach users with a unique brand experience. The drawback is that we require lots of native Android SDK and Objective-C modules, so a good part of the invested time is there. The gain for a app that relies less on native communication, sensors and OS tools should be even higher.

Also it helps us set different testing stages: we use Travis CI for the javascript (business logic), Bitrise to run build tests and @Detox for #end2end automated user tests.

We use a microservices structure on top of Zeit's @now that read from firebase. We use JWT auth to authenticate requests among services and from users, following GitHub philosophy of using the same infrastructure than its API consumers. Firebase is used mainly as a key-value store between services and as a backup database for users. We also use its authentication mechanisms.

You can be super locked-in if you also rely on it's analytics, but we use Amplitude for that, which offers us great insights. Intercom for communications with end-user and Mailjet for marketing.

See more
Travis CI
Travis CI
Appveyor
Appveyor
GitHub
GitHub

I recommend using Travis CI and/or Appveyor in all projects.

Projects using these tools have given me confidence to know that I don't cause any breaking changes. Travis CI and Appveyor have functionality to test components of a project across multiple installation projects to ensure that modifications don't break a project. These tools integrate easily with GitHub and are useful in open source projects that must review contributions from many different people.

See more
Simon Bettison
Simon Bettison
Managing Director at Bettison.org Limited · | 7 upvotes · 213.5K views
atBettison.org LimitedBettison.org Limited
PostgreSQL
PostgreSQL
Elasticsearch
Elasticsearch
Sidekiq
Sidekiq
Redis
Redis
Amazon ElastiCache
Amazon ElastiCache
Rails
Rails
RSpec
RSpec
Selenium
Selenium
Travis CI
Travis CI
Ruby
Ruby
Unicorn
Unicorn
nginx
nginx
Amazon CloudFront
Amazon CloudFront
Amazon SES
Amazon SES
Amazon SQS
Amazon SQS
Amazon Route 53
Amazon Route 53
Amazon VPC
Amazon VPC
Docker
Docker
Amazon EC2 Container Service
Amazon EC2 Container Service

In 2010 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.

Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.

PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.

Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!

Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.

We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).

Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service

See more
Peter Thomas
Peter Thomas
Distinguished Engineer at Intuit · | 7 upvotes · 42.7K views
atIntuitIntuit
Karate DSL
Karate DSL
Travis CI
Travis CI
GitHub
GitHub
Java
Java
Apache Maven
Apache Maven

As the maintainer of the Karate DSL open-source project - I found Travis CI very easy to integrate into the GitHub workflow and it has been steady sailing for more than 2 years now ! It works well for Java / Apache Maven projects and we were able to configure it to use the latest Oracle JDK as per our needs. Thanks to the Travis CI team for this service to the open-source community !

See more

Travis CI's Features

  • Easy Setup- Getting started with Travis CI is as easy as enabling a project, adding basic build instructions to your project and committing code.
  • Supports Your Platform- Lots of databases and services are pre-installed and can simply be enabled in your build configuration, we'll launch them for you automatically. MySQL, PostgreSQL, ElasticSearch, Redis, Riak, RabbitMQ, Memcached are available by default.
  • Deploy With Confidence- Deploying to production after a successful build is as easy as setting up a bit of configuration, and we'll deploy your code to Heroku, Engine Yard Cloud, Nodejitsu, cloudControl, OpenShift, and CloudFoundry.

Travis CI Alternatives & Comparisons

What are some alternatives to Travis CI?
Jenkins
In a nutshell Jenkins CI is the leading open-source continuous integration server. Built with Java, it provides over 300 plugins to support building and testing virtually any project.
CircleCI
Continuous integration and delivery platform helps software teams rapidly release code with confidence by automating the build, test, and deploy process. Offers a modern software development platform that lets teams ramp.
GitLab CI
GitLab offers a continuous integration service. If you add a .gitlab-ci.yml file to the root directory of your repository, and configure your GitLab project to use a Runner, then each merge request or push triggers your CI pipeline.
GitLab
GitLab offers git repository management, code reviews, issue tracking, activity feeds and wikis. Enterprises install GitLab on-premise and connect it with LDAP and Active Directory servers for secure authentication and authorization. A single GitLab server can handle more than 25,000 users but it is also possible to create a high availability setup with multiple active servers.
Bamboo
Focus on coding and count on Bamboo as your CI and build server! Create multi-stage build plans, set up triggers to start builds upon commits, and assign agents to your critical builds and deployments.
See all alternatives

Travis CI's Followers
3886 developers follow Travis CI to keep up with related blogs and decisions.
주영 박
Pranit Harekar
Valdemar Arantes Neto
Franck Gamess
snishizawa5
Michael Li
Adam SPAGNUOLO
amit kumar
Mahmoud Elzoka
Gefferson Oliveira