Codefresh vs Travis CI: What are the differences?
Developers describe Codefresh as "CI/CD Tailor-Made For Docker". Automate and parallelize testing. Codefresh allows teams to spin up on-demand compositions to run unit and integration tests as part of the continuous integration process. Jenkins integration allows more complex pipelines. On the other hand, Travis CI is detailed as "A hosted continuous integration service for open source and private projects". 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.
Codefresh and Travis CI are primarily classified as "Container" and "Continuous Integration" tools respectively.
Some of the features offered by Codefresh are:
- Instant Dev, test and feature preview environments: Enables all team members to run any image as a standalone or composition for feature preview, manual testing, bug reproduction and more. Collaborate on features before pushing them into staging and production.
- Testing with every step: Configure your pipeline to run integration and unit tests with every step
- Instantly test all code changes in the Codefresh build system before pushing to staging & production. Run integration, unit tests in parallel.
On the other hand, Travis CI provides the following key 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.
"Fastest and easiest way to work with Docker" is the primary reason why developers consider Codefresh over the competitors, whereas "Github integration" was stated as the key factor in picking Travis CI.
What is Codefresh?
What is Travis CI?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
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.
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.
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
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.
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 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".
I use Google Cloud Build because it's my first foray into the CICD world(loving it so far), and I wanted to work with something GCP native to avoid giving permissions to other SaaS tools like CircleCI and Travis CI.
I really like it because it's free for the first 120 minutes, and it's one of the few CICD tools that enterprises are open to using since it's contained within GCP.
One of the unique things is that it has the Kaniko cache, which speeds up builds by creating intermediate layers within the docker image vs. pushing the full thing from the start. Helpful when you're installing just a few additional dependencies.
Feel free to checkout an example: Cloudbuild Example
We went looking for one thing "CI/CD with on-demand environment creation".
Within only a few hours with Codefresh and their amazing on-boarding support we had that and so much more!
Codefresh immediately brought our build time down 50%; gave us the same consistent unit and integration testing from Development workstations to our CI environment; and allowed our Developers to create an environment from any Docker Image built within Codefresh using simple yaml files for every Pull Request they created and send those links along to our QA/Design Teams.
This greatly increased the velocity of the Development lifecycle. The Developers had environments running their code with yesterday's data from our MySQL databases in our upper tier environments in 1-2 minutes.
QA/Design Team members were given links in the Pull Requests to review and approve these changes before they were being pushed back into our default branch.
The free-style steps are very powerful and allow you the opportunity to run scripts against other APIs during builds.
We've recently used Codefresh variables and have begun integrating the builds into our Rally/CA Project Management tool to identify when test cases are ran in Codefresh and marking the test cases back in Rally with the results.
I work in a place where I'm behind a strict firewall and where I cannot install software on my computer. At home, I'm building my startup, SimpleWP. We're using Docker for our core feature.
Codefresh made me able to work with my docker images in a super easy and efficient way. I can modify the Dockerfile on Butbucket, the build is automatically triggered in Codefresh and I have my service up and running. If there is something wrong, I can see the logs instantly, make my modifications and it rebuilds automatically. Not only I see the logs of course. I can use test scripts to check if everything was OK. I'm lazy, many times I don't write tests, but this feature made me able to reliably test the results of my build without logging into the containers, which would be really difficult from my workplace.
With Codefresh, my development workflow is amazingly simple, completely online and I can work really fast. I'm not using all their features so don't take it as a detailed review. But what I use, I love.
I have to mention that I also have good experience with their support. They were quick to answer and they helped when I had a problem. For me it's super important.
In the past we used to run Jenkins. The build server always had weird issues and was a pain to maintain. Travis is a great solution for CI. Their Debug build features makes it trivial to figure out why your build broke. The integration with Github is also very slick. One thing they could improve is the documentation on the .travis.yaml format. All in all, great company and very responsive supports. Over here at getstream.io we're a fan. Keep up the good work guys!
Travis CI is our pillar for automated deployment, pull request testing, auto-merging (for non-mission-critical projects), and build testing per commit / release.
It is highly configurable, super cheap, and extremely robust (supports every language and configuration we've thrown at it).
While we usually run tests before commits, Travis goes further and tests with different Python versions and different database backends. It works great, and, best of all, it is free for open source projects.
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 is critical for Linux and macOS CI tests for the Powershell module. Travis runs the same tests we run in AppVeyor in parallel.