That's pretty impressive, given that a build typically hogs CPU as well as IO.
How CircleCI Processes 4.5M Builds per Month
61–70 of 89 posts
Re: How CircleCI Processes 4.5M Builds per Month
#62Earlier quoted context omitted.
If you don't mind tinkering, I highly recommend Buildkite. They provide the management & cloud UI and you run the actual build agents on your own infrastructure. When you get it going it blows everything else away in value for money. We routinely have hundreds of containers on-the-go and as many concurrent builds as we need; this all runs on a large AWS spot instance at a cost of about $50 a month. Added bonus: our d…
You are using a large spot instance on ecs?
Yes, it works very well. Earlier this year AWS automated the process of setting up a cluster backed by a spot fleet[0]. It's a very cost effective way to run lots of containers.
We actually use a combination of on-demand and spot container instances in production to keep costs down; we have some logic to provision more on-demand instances in case of multiple spot outages.
[0] https://aws.amazon.com/blogs/compute/powering-your-amazon-ec...
Re: How CircleCI Processes 4.5M Builds per Month
#63Earlier quoted context omitted.
If you don't mind tinkering, I highly recommend Buildkite. They provide the management & cloud UI and you run the actual build agents on your own infrastructure. When you get it going it blows everything else away in value for money. We routinely have hundreds of containers on-the-go and as many concurrent builds as we need; this all runs on a large AWS spot instance at a cost of about $50 a month. Added bonus: our d…
I'd love to hear more about using Buildkite. It appears to to offer greatly flexible agents with out a heavy cluster to manage or poorly written plugins to deal with...
Happy to answer any questions about it. We've been using Buildkite for a while - it has been a pleasant experience and has let us craft a CI setup whose cost would be prohibitive to us otherwise.
Another similar option we tried is AWS CodeBuild which has per-minute billing and provisions the build machines for you. However, it's very bare-bones and because you always get a from-scratch instance for each build you have to distribute your docker cache which is not ideal.
Re: How CircleCI Processes 4.5M Builds per Month
#64Earlier quoted context omitted.
Apple are a hardware company… they don't make money unless you buy their hardware.
You'd think Apple would be interested in making the workflow for developers easier though so better apps would be made. It's slightly better now but I've done iOS+Android mobile projects before where CI for Android has been easy to set up and CI for iOS has been a complete nightmare.
I think the workflow is pretty easy: buy a MacBook & an iPhone, and load your app onto the phone & test on it for things which the iOS simulator is not good at.
Don't CI your apps, CI your libraries.
Re: How CircleCI Processes 4.5M Builds per Month
#65Earlier quoted context omitted.
You'd think Apple would be interested in making the workflow for developers easier though so better apps would be made. It's slightly better now but I've done iOS+Android mobile projects before where CI for Android has been easy to set up and CI for iOS has been a complete nightmare.
I think the workflow is pretty easy: buy a MacBook & an iPhone, and load your app onto the phone & test on it for things which the iOS simulator is not good at. Don't CI your apps, CI your libraries.
> I think the workflow is pretty easy: buy a MacBook & an iPhone, and load your app onto the phone & test on it for things which the iOS simulator is not good at.
> Don't CI your apps, CI your libraries.
That's not scalable for complicated apps that you can write automated UI tests for though.
Re: How CircleCI Processes 4.5M Builds per Month
#66Earlier quoted context omitted.
~50$ a month buys you a dedicated server with a Quadcore Skylake (i7-6700). The fastest Macbook available right now has about the same CPU power, and comes with less RAM. So no, the Macbook isn't faster than what you could get, but it makes sense if rented CI infrastructure isn't faster for that price.
Where?
Everywhere?
First provider I checked has a multiple server offerings with quadcore i7-6700 and 64Gb DDR4 RAM for 39€/month [1].
1: https://www.hetzner.com/dedicated-rootserver/ex41s?country=g...
Re: How CircleCI Processes 4.5M Builds per Month
#67Earlier quoted context omitted.
Out of interest, roughly what percentage of candidates agreed to take on the project?
A fairly high percentage. I guess filtering for candidates who are polyglot developers comfortable in more than one language helps. The fact that Clojure is used acts as a filter for self-driven and "better programmers" [1]. [1] http://www.paulgraham.com/pypar.html
[deleted]
Re: How CircleCI Processes 4.5M Builds per Month
#68Earlier quoted context omitted.
> Our tests ran almost as fast as they do on a MacBook. This doesn't seem like glowing praise to me? If I'm paying 50$ per month for a container, I want it to be faster than a laptop ...
> This doesn't seem like glowing praise to me? If I'm paying 50$ per month for a container, I want it to be faster than a laptop... Maybe I am doing it wrong but do people create and destroy a container thingy every time they run a test? I agree with you though. I am no expert by any means I'd expect Circle CI to be faster than a Macbook at building things like Google Chrome from scratch . But if the macbook already…
> Maybe I am doing it wrong but do people create and destroy a container thingy every time they run a test?
I create and destroy a container every time I:
* Run a test
* Start a command line environment for debugging (Ruby mostly, so usually "pry" with all my apps libraries loaded)
* Build anything (e.g. update the installed gems via bundler for Ruby)
* Run any scripts that are part of the app.
It means I can be sure I always run things in precisely the environment the apps will run in, including the right interpreter or compiler, right dependencies etc. - nothing "leaks" from my laptop. Nothing "leaks" to my laptop. I can trivially test with multiple different interpreter/compilers etc. without convoluted "environment management" tools that tend to be language specific. Bugs in my script are also reasonably well contained (though I won't trust Docker for isolation as sole protection against hackers, I trust it for isolation against my own stupid mistakes most of the time).
Bind mounts of the source directory ensures I can do live reloading of code etc. when suitable, so I don't need to restart those containers all the time.
Typically starting the Docker container is one of the fastest parts of the above - often my makefile will not just start a Docker container, but for simplicity run the build whenever I do anything (like run the test suite) to make sure I run it in the newest version of the container, and thanks to extensive caching that too rarely adds more than a few seconds.
In a CI setup like CircleCI, though, the "cost" in time of this when building remotely is pulling the relevant source images from their registry, and the images can be fairly big, especially if you're not specifically going to some effort to keep it down in size.
Re: How CircleCI Processes 4.5M Builds per Month
#69Main downside is paid-for parallelism. Ideally (and I'm sure they'll get there) is per second billed builds. Other that that, great job and nice write up.
I think each container can have up to 8 cores. So using multiple containers to parallelise your tests is your choice.
Re: How CircleCI Processes 4.5M Builds per Month
#70Is this the only big success story for Clojure or other companies using the Lisp family of programming languages? I know there is Paul Graham's Viaweb. [1] Does anyone know of other examples? I like the fact that they are a practical company, using Go when needed where "static dependency compilation and fast start-up are more important". I wonder if the ClojureScript's annoucement on integration of NodeJS modules [2]…
We use Clojure and ClojureScript heavily at Peerspace. Best tool for the job for scaling without adding too much complexity.