Travis CI vs. wercker vs. Solano CI

To make sure that I don't push bugs to production.

CI via travis

Testing of Ruby APIs, Chef cookbooks, and builds of iOS apps.

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.

Automated build testing on every commit

Continuous integration

build server and deploy to heroku

To ensure that what works locally will also work for someone else. Also used to send code coverage to codeintel

Travis provides more than one Ruby version setting. So i can test my push directly in different Ruby versions.

For GitHub integration, very easy to use and useful to get a confirmation that a build runs on a clean machine

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.

Making sure things compile, will be adding deploy artifacts someday.

CI for our Github public repos

CI via github

As an automated build and internal release system for mobile apps

I do all of My CI/CD in Travis

Travis builds, tests and ultimately deploys our websites and APIs.

Continuous integration for some of my iOS projects and open source frameworks

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

Travis runs test-scripts on our repositories.

CI and testing server of my open source projects.

Build all the apps! Test all the things! Ship it when it's green!

travis, slack을 연동하여 PR마다 체크하였습니다

Deployment

We use Travis CI to test and automatically deploy our static website on our server.

Build, Test, Deploy

We use Travis CI to test our open source libraries.

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.

We use Travis CI to run our tests on each build and to build binaries used for deployments.

Build the lfzyx.org website source code

Part of the automated build process, running any tests before deployment.

For automated testing and coverage reports

reports

For continuous integration of our back-end services

Automatic generation and deployment of site

For automated testing and deployment

"There are a ton of excellent strategies for speeding up Rails test suites—aggressive use of stubbing/test doubles, decoupling logic from models, avoiding loading Rails entirely—but given the size of our codebase and the velocity with which we’re moving, most of these weren’t immediately feasible. We needed a build system that would allow us to parallelize our test suite so that the real time taken to run the suite was manageable.

Our SRE team went through several different continuous integration solutions in the last year before settling on Solano.

Each of the previous systems had some issue: instability, memory consumption, poor DB management, poor parallelization, painful web UI, you name it. What Solano gives us is an on-premise solution with excellent native support for fanning out tests to multiple threads, running them in parallel, and then assembling the results. It has a great web UI, CLI support, and impressive performance. Since we started using it, our deploy workflow has grown noticeably faster, and the number of wails and anguished GIFs from frustrated engineers is at an all-time low."

CI Server