Buildkite

I use Buildkite because it balances enormous flexibility with easy out of the box configuration. We use it for everything from automating builds (which involves running huge test suites where the parallel builds feature is invaluable) to doing nightly batch jobs for our production environment. Super flexible, amazing tool

Buildkite provides testing of the Rails application via a Docker container with Docker Compose. The Buildkite Agent runs on a small Digital Ocean droplet, runs the integration and model tests, and marks the GitHub commit for Heroku to perform their auto-deployments once the build is green. Buildkite

I use Buildkite because it is extremely flexible and integrates seamlessly into our CI/CD workflow. We run everything on AWS and it is very affordable to run a lot of parallel tests because we control the infrastructure.

When we've gone through code reviews (every code and config change goes through a code review) and feel good about the level of automated testing (no one can sign off on their own code's functionality; a quality assurance engineer or other developer has to verify functionality), we merge our changes via a bot that interacts with GitHub (the bot maintains our versions and change logs). After Buildkite has a green build and our binary is shipped to our repo servers, we are good to roll out deploys to our data centers and to keep pushing the needle on the performance of our system.

#Languages #DataStores #Databases #InMemoryDatabases

We use Buildkite as a CI platform. What makes Buildkite unique is that it lets you run tests in your own way, on your own hardware while BuildKite orchestrates builds and provides user interface.

The Shopify monolith has around 100K unit tests. Many of those involve heavy ORM calls, so they aren't very fast. To keep the shipping pipeline fast, we've massively invested in our CI infrastructure.

The build of our monolith takes 15-20 minutes and involves hundreds of parallel CI workers to run all 100k tests. Parallel test workers allow us to keep shipping. Otherwise, a single build could take days. We have hundreds of developers shipping new features and improvements every day, and it’s crucial that we keep the continuous integration pipeline fast.

When the build is green, it's time to deploy changes to production. We don't practice staging or canary deploys, instead we rely on feature flags and fast rollbacks in case something goes wrong.

#BuildTestDeploy #ContinuousIntegration

I use Buildkite because it's the only CI system I've found that strikes a reasonable balance between flexibility and usability. You can accomplish pretty much any standard CI task out of the box with a simple, easy to understand interface and sane defaults, while the hooks and pipeline systems offer enough configurability to rival Jenkins - but without the misery that using Jenkins is certain to entail.

To speed up our #ContinuousIntegration builds and give us more control over costs and tooling, we chose Buildkite. See blog post for more information!

I use Buildkite because it balances enormous flexibility with easy out of the box configuration. We use it for everything from automating builds (which involves running huge test suites where the parallel builds feature is invaluable) to doing nightly batch jobs for our production environment. Super flexible, amazing tool

We use Buildkite because of its flexibility and ease of use. Their pipeline DSL is very lightweight and allow us to do the more heavy lifting of the pipeline build with other build tools like Make; so while it's extremely flexibility it doesn't limit us to write the entire pipeline in their DSL.