Helpt Nederlandse bedrijven al 15 jaar
bij het vinden van de juiste software
Travis CI
Wat is Travis CI?
Travis CI stelt software-ontwikkelingsteams in staat om hun code met vertrouwen te testen en te implementeren.
Travis CI is voortgekomen uit de open source-gemeenschap en wordt vertrouwd door een gemeenschap van meer dan 700.000 gebruikers en grote ondernemingen, waaronder IBM, Zendesk, BitTorrent, Heroku, MOZ en vele anderen.
Wie gebruikt Travis CI?
Zowel open-sourceprojecten als grote ondernemingen. Travis CI wordt vertrouwd door bedrijven als IBM, Zendesk, Heroku, Moz, BitTorrent en vele anderen.
Twijfels over Travis CI?
Vergelijk met een populair alternatief
Travis CI
Andere goede alternatieven voor Travis CI
Reviews over Travis CI
CI tool that has a lot of value for the money
Opmerkingen: 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.
Pluspunten:
* 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.
Minpunten:
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.
Eerder overwogen alternatieven:
Travis CI is great automation tool is easy to configure and run.
Opmerkingen:
We have used Travis ci for automation of code building, testing and deployment. Travis CI is one of the top continuous integration and continuous delivery tool available in the market. We usually use Travis CI for medium scale projects because it easy to use, few minutes of configure is needed comparative to Jenkins which require skilled professional to configure it. We have used it for test projects as it is free for public projects.
Travis Ci is good for small to medium scale projects, which doesn’t require much of the customization or less complex projects. Travis CI is also good for public and open source projects because it provides free tier for public projects. It’s easy to use, you don’t need any professional skill to set it up.
Pluspunten:
Great thing about Travis CI is it’s easy to use, easy to configure and start running it, you can easily integrate GitHub account and whenever you push your code its integrated and tested on Travis CI. Travis CI doesn’t need hosting server to run it unlike Jenkins which require hosting server. For public projects you don’t have to pay, its free to use for you test and open source projects. Testing on different environment, devices, OS is optimized and run synchronously. You don’t have to maintain software updates for Travis CI unlike Jenkins. It is fast for testing code on different environment by having different jobs like you can have separate job for unit testing and separate jobs for integration testing.
Minpunten:
Travis CI doesn’t have that much flexibility respect to customization as compare to Jenkins. Integration with third-party tools is not too much which reduces it flexibility. You code is accessible to Travis CI which is not good for most sensitive projects. You must pay for private projects as comparative to Jenkins which is free for private projects.
Static matrices and changes to OSS terms mean I cannot recommend the product
Opmerkingen: Our initial years with Travis were successful, and we were quite happy with the product. But over time, the lack of flexibility meant struggling to create and deploy our CI definitions. But the part that killed Travis for us was the change to OSS terms late in 2020. We'd already noticed that our queues would become long, particularly if we had many contributors or maintainers working simultaneously. But with the changes in terms, we quickly ran into a scenario where we ran out of hours by mid-month. This left us with an untenable situation; as an OSS project, we have limited funds, and we would quickly run through those if we purchased a plan. As a result, we are within 1-2 weeks of moving off the platform entirely.
Pluspunten:
When we first started using the product, it was one of the few that existed, and it provided us exactly the assurances we needed to have predictable, stable software releases. Idempotent runs made it possible to know exactly when and why something failed.
Minpunten:
Since we produce OSS libraries, it's important for us to test against each language version we support. Unfortunately, there is no way in Travis to dynamically create a matrix based on the library/package definition itself. For instance, we produce PHP libraries, and our package management solution, Composer, allows us to specify in the package the versions we support. Unfortunately, when we change those, we also need to remember to change the Travis definitions to reflect those changes. This becomes a source of error very quickly - Travis may report all is green, but it turns out we haven't added the new PHP version to the matrix, so it's a false sense of assurance. On top of that, it's impossible to succinctly make discrete jobs that do different things. For instance, I don't need to run coding standards checks, static analysis, and documentation linting for every single job in the matrix; I really only need to run these once. But to do that, Travis forces me to define env variables for jobs, and then use conditionals to determine what to run. This makes the CI definitions very convoluted, and, if you have a lot of repositories that need to do the same, hard to distribute when you have changes to make. Other CI systems address this.
Eerder overwogen alternatieven:
Travis CI: Great overall for over 8 years. Not anymore after travis-ci.COM migration & OSS credits
Opmerkingen: Overall, Travis CI used to be the best turnkey solution for independent Open Source developers to set up Continuous Integration and Unit Testing pipelines. Thanks to bad actors such as unscrupulous bitcoin miners, this once great free open source community service has been morphed into a paid credit-based system. Lack of customer support responses have pushed independent volunteer open source developers out. We simply cannot afford CI testing when our software is free and open source by design.
Pluspunten:
As a long-time user of TravisCI for 8 years, I loved the ease of setting up CI testing pipelines and testing matrices with a single .travis.yml file. It made testing DevOps Chef cookbooks easy and was a great solution that integrated well with test-kitchen.
Minpunten:
When getting a remote VM testing pipeline set up, there are some barriers to ease of debugging. This was primarily due to the lack of live SSH terminal access to poke around at the testing environment to debug job failures. After they added Debug Mode, this became a bit easier. The main problem with Travis-CI was recently introduced with the travis-ci.COM migration. Users were encouraged to migrate projects over to the new website with no way of going back. A new paid credits system was forcibly implemented, with some promise of Open Source credits. All of my projects on TravisCI were free and OSS licensed, so I asked for OSS credits. After a few back and forth emails, I was promised 25k credits. However, after checking in the OSS credits section I still see zero credits listed. It seems that just like that, Travis CI was taken away from OSS users who chose to migrate with no warning about the implications. Travis CI news blog posts explain that this change was made due to some nefarious bitcoin miners abusing their free build systems to mine cryptocurrency. So just like in school where the bad apple ruins it for the rest of the class, now Travis CI has been taken away from small Open Source developers. Please improve your customer support and reinstate OSS credits for independent Open Source developers! Any kind of response or clarity around the application process would be much appreciated!
Eerder overwogen alternatieven:
Essential for software development
Opmerkingen: I am able to conduct a wide variety of tasks from checking compilers, running static analysis, and building documentation.
Pluspunten:
Travis-CI was the first CI system I used on my research projects, and to this day Travis-CI still does the heavy lifting on most of my tests during Continuous Integration. It's extremely flexible; I have workflows that run static analysis, security checks, documentation builds, and more. The features and integrations with a number of other systems (GitHub, CodeCov, etc.) make this my go-to CI. I especially appreciate the support for Education customers, other CIs would be quite expensive by comparison.
Minpunten:
Operating systems support can lag. In particular, support for modern C++ compilers can be a bit tricky (it's an old item many of us have raised). The new plans price some organizations (e.g. Boost) out of using it. Support on the MacOS images is not as robust.
