Travis CI Reviews & Product Details

I like that it is an environment where you can essentially set anything up like you would locally via your terminal. Using Travis CI also keeps everyones code constant with the linter rules in place, and in the beginning helped with learning what in the code needs to be done before deploying it.

I dislike that if a Pull Request was not properly merged with the master branch that Travis CI uses to check against it will fail. So if the references don't match it just breaks, but maybe its just my works setup with Travis. Sometimes Travis feels like it takes longer than it should, but I think this is situational.

Just make sure if you want to use it to build your environment that it meets all the requirements. Basically don't just assume Travis CI is the solution for you.

We use Travis to keep our code honest.

We use it for tests to make sure it passes before deploy.

We use it as the middle man.

Benefits:

Keeps code constitant

Catches errors with tests

Updates linter rules as per the parent it calls from

I really liked using Travis CI when I wanted to deploy changes to the open-source project I was working on - it was very easy to pinpoint which exact tests failed and where I had to go back to fix them before deploying.

It takes a very long time to run through the tests for some reason - the project I worked on was fairly small so I wasn't sure why it took 2 - 3 minutes just to run tests (this also slowed down our productivity in general, although I know there were other ways to run tests running it on Travis was visually the best to see what the outputs were). Additionally, even if the tests did all pass, there were still many moments that the tests didn't catch which made our website go down.

My team used data from libraries from the IT team on campus to find spots on campus that were not being used so users could easily find unused rooms. Our specific project was to predict which spots would be free using past data. The benefits I realized was that deploying was fairly simple.

I knew the tool thanks to the Github platform, it seemed extraordinary the integration that these two platforms have, just by doing 'push' to my repository I could automate validation, integration and deployment tasks with only 1 command. In addition to this you can integrate the tool with Telegram Bot to be aware of the status of the deployment of the application. This is a good tool to use next to github.

when you want to do mass deployment process, the configuration becomes a bit complex, since it does not provide tools to perform these processes from the web interface, you must have advanced technical knowledge if you want to achieve good results.

I recommend this tool to all those who want to automate their development processes and deployment of applications

Thanks to this tool, the unit testing processes, massive deployment of applications, were automated. The times for deployment to production were reduced.

It "just works". The build logs can be viewed in real time (live tail). Lots of useful integrations. travis-ci.org is very popular for open source projects so many fellow developers will already be familiar with it.

The documentation could be better; there's no reference for the travis.yml file so you have to read/search the full docs to find what you're looking for. The pricing is on the high side.

Excellent CI solution. Pricing is on the high side but it's worth it when you consider the time saved.

We use Travis for running tests (automated builds) and continuous deployment. It has standardized our deployment process and saved a lot of time - now we just push to the git repository and Travis takes care of the rest. If there's a build error, it'll let us know via Slack - pretty neat.

Travis has been a very good experience to me compared to using other CI. We went from CircleCI to this because of it's simplicity, the config is very easy and the documentation is really good for the newcomers to using CI's.

The UI I think is the weakest part of Travis, compared to some other CI's, it'd lacking in that front, but not in very wide gap though. Something clean and really modern would do.

Travis CI is one of the best CI's I have ever used. It has great support for web development, is very accessible for new users, has several integrations with other software to make it even better and just overall faster and stabler than any other CI's i have used. The UI though, although satisfactory could be better.

We use Travis CI as a tool for checking if tests are working before we deploy them. We use it as a measure if a pull request for our application is good for deployment. It also has integration with slack and chrome has been really good overall.

Integrating Travis into a project is essentially painless. Create a simple config file and Travis takes care of the rest, even if your app needs to be built via Docker containers or other modern delivery mechanisms.

If you have a lot of devs and a lot of projects, sometimes builds will get held up in a queue.

By switching to Travis we were able to decommission our Home-grown Jenkins infrastructure that nobody on the team really cared to maintain or keep updated. Builds are generally faster and we can more easily have multiple builds at the same time.

Having Travis results directly in GitHub makes reviewing pull requests more informative as well.

Most of the open source libraries use TravisCI - that's what makes TravisCI pretty - love how they support open source community.

Had some troubles time ago to set up a private repository - not sure how it's working for private one now on - but it was so complicated awhile ago.

If you do have an open source library, go ahead and use TravisCI, please do what the most the open source libraries are doing.

All my open source libraries use TravisCI - just for open source libraries hosted by GitHub

It integrates well with GitHub, automatically running tests for new commits, so we don't have to manually ourselves. Forces users to ensure their code is tested before merging with master. The integration is fairly simple with just a configuration file. Granted, if you have a more complex build, this integration can be more complex. Their documentation is fairly extensive though which is good.

The UI can be a bit clunky to use and the view for builds could load faster. It also can get pricey for the paid versions for a startup. If you have multiple team mates collaborating, the list of builds waiting can queue up meaning you're waiting potentially hours (if each build takes 30min).

This tool saves developers a lot of time and ensures higher quality output from an engineering team. I would definitely recommend it and if you have an Open Source project, it's free too.

We use it mainly for automated tests and continuous deployment for our staging environment. It saves our developers time from handling these tasks that take somewhere between 30-60minutes each time. And instead free them up to be working on other things. It means all code is now always tested routinely without any excuses for lack of time/laziness.

I love the integration with Github, when it adds visual information to a pull request to let you see how a build is progressing and what problems it has (if any).

I love that it's very easy to configure without any hassle.

I love the badge you can put on a website or in your readme to show whether the build is passing or not.

I love the fact that it has built-in support to deploy to other vendors, like Heroku

Difficult to build native .Net projects without using Mono, but that's more of a disappointment with the .Net build ecosystem and not a fault of Travis as such.

Also, pricing - I've only had need to use the free open-source tier, as all the projects I've worked with are open source, but the price of the first paid tier ($129 per month!) is, for me, quite prohibitive and really puts me off making the leap to pay for it.

If there was an even cheaper tier, for example one which was say $30 per month with 1 concurrent job and limited minutes per month, but allowed private repositories, then I would probably make that jump. I just feel there's a big gap in the entry-level pricing tiers.

Give it a try and not be put of by big words like "continuous deployment". It was so easy to use.

Developing a website for my wedding with another developer. We quickly realised the benefits of Continuous Deployment specifically, and more importantly, how easy it was to set it all up. Everyone should be doing this!

Travis really shines on their language support as well as capabilities. Its UI is nice, very nice, with a dashboard that allows you to check the status of 6 or 7 projects at the same time (depending on your screen size and resolution) and their status.

The real downside of Travis is that you need to add a file to your project to start using it. This is mandatory today and this file can be quite complex. This leads to some "useless" commits just to correct some configuration in this file and check if it works on the Travis dashboard. Once you tweak the file correctly, you don't have problems anymore with it.

Travis is being used in many open source projects already which is a very good sign. I really like it but today I would prefer to used something like Drone.io for my CI. I haven't introduce CI or CD into my workflow as to take time from my development schedule and Travis fits quite nice (once you configure it correctly).

Travis is very well suited for open source projects as it has direct Github support with a simply click so, if you are it the open source community, give it a try.

I use Travis in my open source personal projects as my main CI workflow. I mainly use it in the most common way: to check unit tests that I have on the project every time I made a push to Github and feel sure that I haven't broken anything.

I like Travis CI because it is really simple. All the configuration is in just one YAML file. We can list all the build steps we want in the build lifecycle with simple commands, just like as we do in the terminal. No GUI clicking, building is required. The second best thing is the GitHub integration, which is flawless. You just add the conf file, enable the repo, and you got full integrated CI with your GitHub repo. Finally, as an open source developer, i love that Travis CI is free for all OSS repos.

Sometimes the service has outages, but i am not a customer of the paid product, only the free for open source projects. The build machines are also little bit slow. The CI is simple, but maybe too simple: you cannot see your working directory, cannot add new SDKs easily etc.

I would definitely recommend it.

If you are familiar with terminal environments this is the CI for you.

* Incredibly fast - jobs are started nearly instantly

* good limits for free tiers

* very IT savvy and customer-centric support team - they reached out to us about hitting limits and understood our software limits that were triggering some issues

* website is occasionally slow or laggy, could be slimmed down

* Programmatic APIs are not the quickest

* Team is slow(ish) to respond on complex github issues (granted, I was on a free tier!)

* No mechanisms for dynamic build matrix configuration, it must be done statically

* * This is often called "touchstone" builds in other CI systems, and by executing initial sanity checks and then scheduling followup builds you can prevent unneeded resource consumption and get the max value out of your current limit tier

Just buy in, Travis is worth it. GitLab's runners are modeled after Travis jobs and are quite similar, but GitLab does not provide the same level of amazing support

Needed very rapid develop-iterate cycle to help convince OSS community members to devote their free time to our (quite complex) software stack that needed a *lot* of experts from different fields. We saw community interaction increase massively (4x) after we started using Travis-CI as domain experts were able to quickly propose a pull request and have Travis help them verify it without them needing to set up a 3-computer system just to run a benchmark and verify the output.

The best of Travis CI is it's user-friendly GitHub integration. If you are using popular programming language - you will not get any problems. Moreover Travis CI provides huge capabilities for further customization. You can use default patterns to configure your build, tests and deployment or write it by your hands, because Travis CI provides Linux shell where you can do anything you want. Travis CI docs are also user frienly and easy to understand.

Good integration with some services like Coveralls, Docker Hub.

You can use Travis CI only for Linux and Mac builds. If you need only windows - Travis CI is not your choise.

If you are needed to use sudo - your build will start on low priority outdated infrastructure. That means longer build time and longer queues.

Advanced configuration requires good knoledge in linux command line instruments, because there is no graphic interface for it.

I recomend to try it by yourself. Just open docs, find your programming language and enjoy!

I am using Travis CI to test my libraries, upload coverage to coveralls and deploy documentation to GitHub Pages. The main benifits are from GitHub integration. With Travis CI you no longer need to check build state for the different platfors of the pull requests by yourself, Travis will do it for you. After merge Travis CI will deploy documentation, binaries, make a tag, publish, or anything you want it to do automatically.

Integration with github is great and allows to simply run tests on commits and monitor health of the project.

Pull request checking is also a major, especially for a large open source project, because it simplifies pull request review process.

Run tests on multiple configurations and multiple python versions is a great for library developers.

Travis CI dashboard is pretty clean and informative.

It became harder to setup integration with a private repositories, if you are not owner of this repo, but this might be because of github restrictions.

It might have a lack of flexibility for a large projects, but in my practice I never met this boundary.

It's pretty good and could solve most of the CI related problems

I use travis CI for running tests for my github projects. It's free for a small teams and perfectly fits for a python libraries developers

I am an open source developer so naturally I have a bias for Travis CI. I mostly use Travis CI for my open source projects. And I have never felt the need to shift to another CI server out there in the market. The documentation is good and if you ever need any help, the support team is always there to help you out.

My only complain would would be linux only builds. This is where Circle CI is essentially ahead. If you are building something cross platform, you will have to use something else along with it.

They were telling about Windows support coming up in the later stages, but I don't see it anywhere soon.

I would Travis CI to everyone who wants to automate his build automation, continous integration. It's free for open source projects so I think it is a no brainer on what to choose

Mostly all things open source. I contribute as well as make a lot of my tools open source. As because of this I get a lot of PR's on github. And running tests is essential for merging them.

Before using Travis, I tried many other tools and even used TeamCity for a few months. I love how Travis is so simple and powerful at the same time. Each time I deploy anything, it's only writing a few lines to configure how Travis will test my application and everything is working right away from the first commit.

For some kinds of applications, it was a bit difficult to configure Travis. For Grails for example, I had to guess how to configure it because the documentation did not cover it.

Read the instructions for each framework and configure the notifications correctly. If you don't get notified, there is no use for Continuous Integration.

When working as a team with TDD, it's important to keep the tests passing at any time. Travis makes it very easy to check if that's the case. If it's not, it makes the person responsible know it by annoying him with awful red colored mails until he fixes it.

Simple and flexible setup. It supports a variety of technologies, and it's free. There are many examples out on the web and the Travis docs are detailed.

Travis doesn't scale well. I currently work on a project that uses 4 matrices that each run about 30 minutes. That in and of itself isn't the bad part. Travis limits resources for non-paying customers (as they should) and it often takes a long time for tests to start running if you have many contributors (10 or more).

If you're an open source project this is a great option to add CI to your project.

Before every pull request merge, Travis runs to ensure that our tests and some set of minimal functionality will work on the site. Without this, it'd be impossible to keep all the tests from breaking constantly.

I write some new code. I push that new code to my repo. Now it is getting built and all the tests are running on Travis CI. If they pass and everything works, that code gets deployed into production - simple and automated. Takes a little bit of configuration and setup initially but payoffs greatly in the end.

I have no complaints right now. So far it has been very straight forward and easy to use.

Right now, for independent development this system has worked great. I can't speak to larger projects or enterprise projects but I think it is worth considering if you are an independent developer or a smaller group of developers.

I usually write code online in a cloud editor. I then push my code to Github. This triggers a build of this new code in Travis CI. If this code passes the build and test process then it triggers a deployment in Heroku.

The seamless integration with Github is the feature I like the most. Travis CI provides free continuous building with open source projects hosted on Github. Unlike other CIs, running Travis is as simple as adding a configuration file to your existing repositories on Github. The configuration file can be easily made with reference to their extensive documentation. Also, Travis allows root access which is a nice feature as well.

The builds sometimes compile very slowly. Also, since it is run on Ubuntu and its dependencies aren't always up to date, which implies one needs to add more to the configuration files, slowing the process. However, I do not think it is a big problem for me.

Also, Travis runs on Ubuntu and not on Windows, which means cross-platform compilation is made harder.

If you use Github, then Travis CI is a no brainer. Try it out!

Continuous integration for private repositories hosted in Github. Travis CI private builds are free for students through the Github Developer Pack.

Travis is very easy to setup for any of your projects, and it's free to public projects on GitHub. The UI is great and it gives hints to help you finding out what you've configured wrong. Giving that build automation is a must have in your toolbelt nowadays, Travis is of course the best choice for public GitHub projects.

The paid plans are very pricey, which avoids me to use this great tool in my startup projects at MVP stages - in which I have no profits yet. I think there could be a cheaper plan, even if more limited, for startups at MVP, because build automation is a must.

You can take a lot of advantage of using Travis for your open source projects. If you don't write tests yet, learn it now and integrate your projects with Travis. Let some tests fail and you'll understand how Travis automated build and emails are a lot helpful. The paid plans are pricey but worth the job.

I've been convinced to open source many of my private libraries only to get advantage of using Travis for free. Automated tests are very helpful on discovering issues early, and a build automation tool which emails you in case of any failure will be your best development friend. I can't think on starting a new project without Travis.

The absolute best thing with Travis CI is that it is free for open source projects. It is easy to connect your Github account and configure it to compile and run all your tests upon new commits. I think that Travis CI is a given choice if you are working with an open source project.

I personally wished that there were more configurations options to use. For example, one of Jenkins' strongest features is that you can configure it and personalise it with additional configurations or plugins. I wished that these options existed for Travis CI as well. Travis CI will look rather slim compared to Jenkins in certain aspects.

Give it a try if you are working on a open source project.

The benefits with Travis CI is that they host and manage everything. They solve

I like most the Github integration part of Travis CI. When you have an existing Github (either open source or closed source) project, it can work seamlessly with the existing structure and integrates on 1-click without almost any effort on your part. The only thing that you need to add is a configuration file, which is usually very well documented in their docs and also shows the whole log of what happens during the build, so you can catch your mistakes easily.

Travis CI is essentially a linux only CI. They say they are working on supporting Mac as a platform too, but due to the nature of licensed products, I dont think it will be free to use for open source projects like the existing one.

It doesnt seem like a huge put-off considering that it is the best and easiest CI server I have used, but if you are working on a cross-platform tool, it is downright essential that your tests work on all platforms in the same manner so that you can save your devs the headache of maintaining and testing on different OS. That is where it falls short, it doesnt support Windows or doesnt plan to in the near future.

You might not care about programming on Windows, but you do need to care about your users on that platform and make sure that they get the same great experience as others. That is why testing on all platforms are necessary, but sadly using only Travis CI you cant do that. You need to also use something like Appveyor to test on Windows.

Travis CI is not a cross-platform solution, you'll also need some other CI that builds on Windows for cross-platform projects. Appveyor can fit the bill there.

I am using Travis CI to test my python modules on linux, including some open source projects.

Earlier, it used to be that devs tested all the code on their own machines locally before pushing to Github and make sure all the tests passed. But the problem is, this test results are only available to that particular dev and so others working with him cant be sure of the code quality, specially when the submitter is new-ish. Its much better when everyone can see how that Pull Request performs with existing test cases and be sure that nothing much will be broken if it is merged.

Also, when a issue/bug is reported, it is sometimes hard to replicate for others and the question comes of whether it is because of the configuration of that particular machine, or a weird bug in the project itself. So, putting that potential bug as a test case lets us see the status on the CI and determine if it exists on a standard system.

Travis CI is a real life-saver if you need to test your application against different environments. You can test against different language runtimes, different web browsers, different web servers, you name it. The best part of this is you can mix and match these any which way using test matrices. This is just something you can't do manually.

Travis CI includes most commonly used computer languages and server technologies. However, if Travis doesn't have something that you need built-in you can script its installation yourself. As long as something can be scripted you can use it on Travis. And really, what can't be scripted?

The integration with Github is really great. Most of our staff live in Github and don't even need to go onto Travis CI's website. Every pull request and commit shows the current build status right within Github.

When trying to get a build going specifically for the Travis CI environment it's sometimes frustrating when you make a mistake and then have to wait for the entire commit process to run through before you can try your next build. It would be nice if it were easier to test Travis CI builds locally when initially developing the build.

Start with a basic .travis.yml file to get your continuous integration going. After that there are a lot of options in .travis.yml. Make sure you check in from time to time to see what is offered.

We have a popular open source application that is run on a variety of web servers. We use Travis CI to automatically run our unit tests against the various deployment environments. We use it to test pull requests before they are merged into the master branch. We use it to test against new versions of server software before we deploy it on our infrastructure.

Our main use of Travis is to have a company-wide check to make sure our software is always correctly building.

Is easy to configure and allows you to get really fast to the matrix of testing scenarios and version of your application or library. It enable almost all tools available now a day. Containerized testing methodology that ensure isolation of execution and results. It enhance and support open software development, helping thousands of projects.

It does not provide a tool to debug the container on execution. It should provide an ssh kinda like tool to interact with the testing container and reduce time on debugging tasks.

You will love the easiest of configuration and how quick you can get to your matrix of testing. It presents to your a great set of tools that will allow you to CI/CD and automate test in a few minutes.

CI private and open source projects.

The testing framework looks rock solid, it will add itself to github hook when turning tests on from travis interface. Just a push and it starts building the project. As the outputs are directly copied over from console, errors can easily be tracked. Allows root access so that is a plus. Dependencies can be cached so build times are reduced. Travis even gives you a neat icon to put anywhere to show build status. The web interface shows who last committed, i.e. who caused this build to run, build status for diff. branches and build history. It is a minimal ui approach that also does not eclipse information. Emails me with the build status.

Slow builds. Sometimes builds take ages to actually run, so much that I start to mash refresh the page. Still not platform independent, for windows, you have to look somewhere else. It runs ubuntu 12.04 so the packages aren't always updated and have to install them using travis config. dependency directive. Testing on a specific linux like RHEL (for me) could come handy as one that might not fail on ubuntu can fail on RHEL (apt and yum). For fairly standard builds, .travis.yml config is quire easy but anytime Imove to something that is not officially supported, I have to manually manage the dependencies.

Make sure you have a supported language and build framework, the first setup will be way easier this way and will not scare you away. Builds can be configured to your heart's desire but READ THE DOCS first.

Testing scripts for work is much easier now that I do not have to deploy in a VM running locally and configure it to notify.

Creating a build is very simple and consists of checking in a simple YAML file, which contains instructions for build steps. All commits to the master repository as well as any branches or pull requests are automatically built, with a check summary added to on the appropriate pull request, so that you know the code has run through all the tests successfully before merging.

Builds themselves are very fast (owing to the container-based architecture if sudo is not required) and there is a wide range of available software (other software can be installed in the Ubuntu Linux images using APT), or else pulled from S3.

The user interface is extremely simple and Travis-CI is free for open source projects that are published on GitHub.

At the moment, Travis-CI doesn't have support for Windows (this was a key strategic opportunity for AppVeyor). Unfortunately, this means cross-platform builds will be very fragmented (duplicated build configurations have to be present in both travis.yml and appveyor.yml). The Mac support is not completely seamless, because the list of available software on the machines is different (and obviously Mac doesn't support APT). It's unclear whether these are really solveable problems in general, since it's natural that there will be differences between platforms.

If you have an open source project on GitHub, it's practically a no-brainer, though you'll likely have to combine it with AppVeyor for cross-platform builds. Other options include Circle CI and Drone.io, both of which offer free builds for open source projects. All of these have nice build status badges that can be added to your README.

Continuous integration builds for open source projects. The key benefit is that Travis CI provides free builds, notifications, and reports/dashboards for open source projects.

I have been using it for only for a few weeks and the best thing is the ease of use of the travis.yml file, my framework/language is well supported, mind you. It works very well with my ruby projects and good enough with c++. The web-ui is nice enough that builds can be tracked easily. Also a good thing, the badge that can be included anywhere (most commonly in github readme.md) to track most recent build status. Another good thing is the github hook, as with every push build is triggered automagically.

Language support. One, it did not support vala projects so that was it. Two, for c++ projects to use c++11 with g++ or clang, you have to jump through a lot of hoops, change your travis.yml file and wait for something to break. Another big problem is the wait time, it takes a LOT of time for the build to start after making the latest push, this is where appveyor is better. So, if you are using travis as your only test system, don't. Windows support is also not present currently so that's a problem for VS projects.

Travis is one of the most popular CI systems out there. Although not as easy as one click, one can easily set up a project to use travis in well under an hour, for well supported systems. I recommend setting up a small test project to try it. If travis meets your specs, then go for it as it is well integrated.

The need to state build status explicitly in every push is gone. I can simply push to github and it will let others browsing my project know if this version is usable or if they have to revert to a previous release.

Clear configuration specification, wide user community, fast support and updated software in the stack.

In addition to that, travis-ci has been a major contributor to the growth of the github ecosystem and to its community: they simply kicked out a free tool that did what an open source project could never afford to help.

Some of the project even sponsored travis-ci just because of the major involvement it had in helping the open source software folks.

In addition to that, defining matrices of supported software versions is quite easy, compared to (for example) setups like Jenkins-CI, where setting up such a matrix requires a lot of experience and time/resources.

Console output in travis-ci is not streamed, but rather "downloaded" to the client, which makes scrolling through large logs a bit painful, and sometimes causes travis-ci to "force" the download to a .txt file instead

Get started and follow few major repositories in how to set it up: travis-ci is a good tool, but like every tool far from perfect.

Travis-CI is CRITICAL to software quality and long term support. Without a tool like Travis-CI, no guarantees about software quality can be given, as software upgrades are a moving target.

Basically, if you cannot prove that your software works over a quite big amount of different environments, then you cannot prove that it is stable, well supported or working at all.

Really like the automatic tests, makes sure nobody pushes anything to the repository if it ends up breaking the repository. So you always wait for the green like from Travis ensuring you can push.

I don't have a lot of negative things about travis, I used it for one of my repositories but I do sometimes find it troubling which tests did it fail and why exactly.

It takes a little while to get used to, but it is a must have integration with your GitHub repositories if you need to make sure certain things to remain the same.

I'm in a non profit organization, ACM, and we use travis to make sure when we update our website with new events and workshops we don't break our repository.

Travis CI is a great CI service for just about any Open Source (linux-based) project.

Things they do well:

• Dead simple setup and integration.

• Easy integration with Github

• Great documentation, I've never needed to file a support ticket.

It has been a few years since I've looked into their private repository pricing, but their public service is top notch.

The wait times can sometimes get pretty long, but if you're not paying for the service, that is generally more an annoyance than a blocker.

Travis CI is probably what you'll want to use for most Linux based Open Source projects. If you have other OS requirements, you'll probably need to look elsewhere.

We needed a simple solution for running tests on Open Source projects, and TravisCI is easy for contributors to integrate with, and reliable as a provider.