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 like how easy it is to deploy and get up and running with this software and configuration files, etc (e.g. it's essentially just a commandline which is nice). It was also really nice for all of my open-source projects while travis-ci.org was still running. I could deploy and have builds run without having to worry about money.

Ever since the move to travis-ci.com, support has been terrible and I've used up all of my free trial credits on my open-source web application's Cypress integration tests (https://github.com/tutorbookapp/tutorbook). I contacted support 5 days ago and still haven't heard back about getting more open-source credits for my account. I seriously miss travis-ci.org (though I completely understand the problems with cryptocurrency mining, etc).

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.

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 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.

It was a good choice at the time. But I am not sure if there are now better alternatives. I would especially check for a docker based build system.

Travis has a lot of features which can be setup easily using configuration files. It is free for open source products and not to expensive for company projects.

Quite often builds are stuck which leads to a huge stop in developments in hour company because we pretty much rely on it. Also the builds starts quite slow.

I like that I can see the live status from GitHub and that the UI is very simple. I can easily find everything. The console output is colorized (it's not in other CI software I've used).

Sometimes parts of log output is collapsed, which has hidden an error for me before. It took a while, but my team figured it out.

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.

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.

The reproducibility trend is gaining momentum within the academical research community. CI usage, now a must have for software engineering concerns, can easily be stretched to address reproducibility issues and is thus being rapidly adopted.

- navigating the smooth and complete interface (with a nice github integration) - logs are detailed, thorough and hosted for a long time - jobs don't get to wait for long delays once triggered - great (and generous) customer support - nothing to install on premises

Every CI offer must face quite technical challenges to address specific/advanced services like dealing with credentials or managing sophisticated job workflows. Travis CI does the job quite nicely on such issues yet the learning curve can be quite steep at first. Yes, Travis CI does offer a thorough documentation, yet getting all the tidbits properly aligned can be a tedious task at first (your mileage may vary).

I would say 'yes' for TravisCI 2 years ago, but nowadays there are better alternatives to this product, such as Github Actions. My overall experience with TravisCI started quite positive but ended negatively because of the unreliable service they are providing at the moment. If you are running a critical business with 0 tolerance to downtime, TravisCI wouldn't be a wise choice nowadays.

TravisCI did a great job for many years, across different CI/CD tools, by providing a rich feature set and well-documented functionality.

Unfortunately, TravisCI is not very reliable. It's having constant downtimes for many months. TravisCI announced the deployment API v2 for a long time ago, but never released the stable version. On the other hand, after the recent acquisition of Idera, many talented developers have left the company. Therefore their development speed and shipment of the important features seem to be delayed.

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.

I like the ease to setup the CI for automating the deployments in the different applications

probably the cost if you can start to use it and don't have an idea of estimate cost

We have had a very positive result with Travis and we implement it on ALL of out projects from simple link checkers to fill docker build pipelines, it gives us single point of reference and consistency in all of our projects.

One of the key things was the direct integration with github making the running of jobs seamless to the developers. The wide variety of tools and language support are also very important.

The config files can be tricky to write when trying to adopt new features.

Travis CI is great when it works. I can develop, pass my local tests, then push to github, etc and Travis CI will make sure that my tests pass on a variety of different virtual machines. That is great. I also like the rainbow flags.

I am perpetually confused when things break. On the good side there is fairly extensive documentation. However, a lot of times it is still chewing gum and duct tape. Big sticking point is interacting with services like coverage and code quality tools. I also never quite figured out what the deal was when they switched from Travis.org for open source accounts to travis.com. The transition was super janky, and I still have projects that I think are in the old system, despite trying to bulk transfer all of them.

Globally is good but it's necessary to use two CI software.

Easy to run and find some example No breaking change

1 hour limit for iOS build. You must use two software ... Not a lot of new feature

I used to like your approach to give back to the open source community.

That you changed your approach to giving back to the open source community.

- YML configuration file - Familiar UI - Easy to get to "hello world" stage

- AWFUL support - High price, slow builds - Confusing billing options

overall a great tool for running CI tests automatically.

Remove the manual work in running tests before merging code. Also it's scalable to multiple branches and developers. And it give viability on how the build is broken if any issues arise.

1. A bit slow comparing to running the tests on local machine. 2. Have a verbose limitation of 4MB.

I love the ease of integration with CI workflow for github and heroku

Slow to pick up hooks from builds on occasion

easy to integrate with our software process

The cutover from free open source unit testing to the subscription model has been painful. I submitted a request for help after 'paying' with freely allocated credits for testing when I didn't need to. It seems that at migration, the 'use credits on OSS' setting is set to true - great if I need things done quickly, but I never expected this behavior. It would be like going to Disneyland and using your express passes on the first two rides of the day, when you thought you would be saving this for later. I am now reticent to move forward with expanding use of Travis and am considering alternatives that are a bit less convoluted in terms of understanding how to set up processing.

I found that it's easy to get started with travis-ci

Advanced feature are not documented well (or may be I don't find it easily)