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

TeamCity is our main continuous integration server. It starts creating builds and running tests based on commits that we make in our hosted bitbucket repositories. From there, we have a set of configuraitons that can deploy the built and tested artifacts (web app, batches, db, etc...) to a stage or production server. We still release manually, but we release often, and TeamCity has nice features to help us roll back when things don't work out as planned.

TeamCity builds then copies to each web tier via a powershell script. The steps for each server are:

• Tell HAProxy to take the server out of rotation via a POST
• Delay to let IIS finish current requests (~5 sec)
• Stop the website (via the same PSSession for all the following)
• Robocopy files
• Start the website
• Re-enable in HAProxy via another POST

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

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.

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.

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.

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

I'm using a selfhosted TC as Referenceplatform, and use travis with another configuration.

Continuous integration for iOS apps.

Build system.

CI Server