I started using Travis initially because I needed a way to have consistent builds of our desktop software (built on Electron). Travis has just the tools I needed to make this happen. Doing local builds of the software was processor intensive, I had to go check the status of the build and I was always changing software on my local machine so sometimes builds would fail because I changed something. Travis has completely containerized build machines so you get the same result every time. We now use it for building all our software. I don't know what we'd do without it.

* Affordable (it's priced based on users/seats) * Documentation is solid and easy to follow. I've never needed to contact support. There's good online Q&A since Travis has a large user base. * Versatile (whatever software you're building, there's a recipe for it) * Github integration : you get realtime build status RIGHT in Github which is awesome, once you get your system set up, you rarely ever visit Travis again. It just works.

There's really nothing I didn't like about Travis. Some of the quirks of Electron were the trickiest things to figure out, but that's not Travis's fault. There's a little learning curve when you go from building locally to building remotely with Travis where you need to understand how to set environment variables and retrieve those values in your config/script.

I'm very happy about Travis, until now I found always an answer for each need I had

1. Documentation, maybe the most important value 2. Configuration flexibility in particular GIT SSH custom keys, env variables with sensitive information, build trigger (with inline configuration... very useful for testing configurations), machine SSH encrypted keys, configuration imports, custom scripts 3. Easy integration with GitHub

Permissions check (it's not so clear understand who can build, who can view build history, who can edit configuration).

Overall, beyond the pricing switch, I had been very happy with Travis CI. But, after this pricing change without any notice, I have become unhappy with it. At $85/mo to build two projects without any concurrency (it's slow), I'm become less interesting in staying a customer.

I liked the ease of use getting Travis setup, the caching, and the build matrix.

I think the concurrency model is terrible. Sometimes when I want to deploy code to staging and production, I have to wait for each PR and commit to build before the push happens. Sometimes this takes 20 minutes for all branches to finish building before a push can happen. Also, I'm very unhappy with the pricing changes roll out. I have been paying for Travis for a couple years now. All of a sudden, my iOS team said they didn't think our builds were working any longer. There were a bunch of builds that didn't go through, saying we didn't have enough credits. Digging in, I realized your pricing model changed. So our builds have not been going through for close to a couple months now. I never received an email that you would be changing the pricing which would then break our builds. This to me is a botched roll out. You should have specifically told me that my iOS builds would stop working. In our dashboard, it just shows that our last build was successful 2 months ago. Not that no more builds were happening. This is unacceptable. So much so, that I am actually now reading the Travis CI to Circle CI migration document. Circle CI seems like a cheaper option for us now.

Good experience - got hooked on the free trial, but it's time to move on as its costing an arm & a leg.

I really like Travis CI, creating .travis.yml files is easy enough & I love the interface for seeing my build progress. That said I'll be moving off of this platform very shortly.

The cost is insane - Azure DevOps offers pipelines for free, my AWS sites (5 of them) cost less to host than my Travis CI subscription, AWS has a DevOps implementation that is about $15/mo - even if Travis CI was at $20-$25/mo I would consider it as a solution.

Overall decent experience with the product. But it seems like when they switched from .org to .com and changed their pricing plans it really threw people for a loop.

Really easy to use, workflow was easy and UI is nice for debugging. No complaints about the product.

Too darn expensive. $69/month is too expensive for me and the one-time credit allowance would only get me so far before I have to switch. There needs to be some way to purchase minutes/credits on a pay as you go plan or a monthly allotment on a $5-10 a month plan.

We see it here as less and less professional. It started with a lot of time to get new images, the problem of running after 4PM (Berlin time), the cache for ccache that suddenly disappear (which makes us use even more credits, obviously), and we are missing more and more CD. It really feels as if, after Travis was bought, that the board decided to "cash in" money. You even need to pay credits now for OSS? How is that supporting it?

I liked the ease to setup a new project with it, once you know how to get around the product.

For sure this new price plan, that was announced a day *after* it was put in place (seriously?). It costs us more than half of the credits to make just one build. The price per minute is just insane. I can have more workers and unlimited build times with Azure DevOps, for about the same amount of money of just the subscription alone (so not counting those Travis add-ons). When the credits are done, then the CI will just block. You need to close and reopen the PR. Problem is that we have other GitHub integrations, so this makes the process really painful.

The product is easy to use -- even non-technical people in our team are able to have a look at it and understand why a test failed. It is good that it provides much info about each step it runs

The dev documentation can be improved -- we had some hard time setting up our acceptance test infrastructure as it wasn't clear to us where to set environment variables. Sometimes it takes a long time for Travis to indicate that a GitHub PR is being tested by displaying the orange dot -- not sure if this is a Travis or Github issue, though.

It works. Which is always a good thing. Other tools exist, but Travis always seemed the simplest to implement with GitHub.

Seemingly no reason to change things but reworking the domain. Not exactly sure what the whole point was.

Travis CI can be easily connected to a GitHub repository, making it easy to automate builds and deployments and guarantee the quality of the code with tests. It also has a big community that helps troubleshoot any issue.

Travis CI does not offer dedicated build environments for the builds, which means that the builds are impacted by other builds running on the same shared infrastructure.

I have used it for deployments, software integration, and testing.

You can deploy and make integrated development environments with this. This facilitates testing and integration of software.

It is complex to set up. You have to read the documentation that is not too easy to follow. You could get better results following other tutorials.

Travis builds, tests and deploys our software to staging and production environments. It is immensely useful, and critical to our software development pipeline.

Generally very reliable, customizable, extensible. Easy to debug. Is a workhorse.

Sometimes you'll get builds that won't debug, or builds stuck in the queue forever. This is generally because of some piece of travis infrastructure that has suddenly stopped, but there are no notifications, nor status indications that anything is wrong. Customer service can take the better part of a week to respond, or not at all.

Honestly I can't say it is better than jenkins. I assume for the compay not having to deal with management and updates is an advantage, but from a user point of view is more or less the same thing. And jenkins blueocean looks way better.

It works. Does what I expected. Not a fan.

UI has lots of room for improvemente. As an example Logs screens are annoying, because the scroll hides the header. I only want to scroll the log , not the full screen. When I hover over a build I see a message like 'build #123 passed'. The build number does not tell me anything, it would way better to see the author and the message of the commit, it will save me a click Everywhere you have a commit you should see a tooltip with author/message, not just the link to github

It was pretty much ok, even though the CI infra stayed behind the competition in terms of software used in builder images, and also available features. Perhaps that was the reason the company started struggling at some point in time - with GitHub and GitLab seriously upping the game, and Circle CI having started quite long ago and moving around faster than Travis CI - it was more inertia and a bit of simplicity that kept me around. And then the company simply ghosted its open source users for something like 4 months, stopping the free service (despite previous promises they wouldn't) and saying nothing on what to expect. Needless to say, for CI it was a complete dealbreaker. I went away and never looked back.

Back when I started, the onboarding was very straightforward, as long as you used GitHub. Fairly reliable for my low-profile usage. Simple and direct user interface.

It grew worse when the company behind Travis CI got sold; downtimes became more frequent, builder image upgrades didn't really get up to speed - but the worst was to leave an extremely short runway to the free tier for open source users with no prior announcement. That's not so much about the software, it's about the company. Free tier or not, in CI segment you just can't afford such things.

Its easy to use by default in new Ember web apps.

All configuration goes in a single monolithic travis.yml file, and the syntax of this file is very mysterious. Understanding what a particular configuration does is difficult, and its difficult to figure out how to satisfy new requirements. In contrast, github actions allow for the separate configuration of many different workflows, and offer comparatively much better documentation. We mostly continue to use travis because we've already figured out how to configure it for our basic needs with a few projects, and our company has already purchased a plan. Its difficult to switch to another system, largely due to company politics.

It's easy to use and configure and also a nice user experience.

It's expensive in comparison to other solutions

Good, but can be

Travis is the only ci tool that have VT-x enabled! It's also well known, simple to use.

Paid compared to github action. At least it could be cool to have come montlhy free credits, for just a few to maintain some OSS project in RUN mode. Not so configurable: I can't come with my own VM ISO so I'm forced to download all prerequisite package every time for each builds: most of my credits go there... As I'm part of multiple orgs, it's hard to know which credits are spent where. Also, the authorization mecanism is not that clear: I don't know exactly what travis sees from my github infos.

Does not work, no documentation of how team permissions are supposed to work.

At first Travis CI was an easy-to-use way to run the test suite of our Ruby On Rails app when branches were pushed to GitHub. Then it locked me out of accessing the build results and just does not work any more.

Github integration broke so I can no longer access the service, only 1 developer on my team can access it.