
How CircleCI Processes 4.5M Builds per Month - emidln
https://stackshare.io/circleci/how-circleci-processes-4-5-million-builds-per-month?ref=reddit
======
priornix
Is 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]
changes that? Also, Lumo [3] is definitely a move in the right direction for
this, addressing the slow start-up times for Clojure/ClojureScript, making it
suitable for shell scripts and CLI binaries.

> Having a lingua franca also helps reduce overhead when engineers want to
> move between layers of the stack.

The way I see it, Clojure allows you to use a single language and syntax from
the super heavy backend stuffs, to the front end and now to small, fast CLI
tools and scripts. A candidate for the "Business English" of the technical
world as it were.

[1] [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

[2]
[https://news.ycombinator.com/item?id=14754614](https://news.ycombinator.com/item?id=14754614)

[3] [https://github.com/anmonteiro/lumo](https://github.com/anmonteiro/lumo)

~~~
pcr0
I don't think Node solves the problem of static dependency compilation and
fast startup.

~~~
mhluongo
It solves fast startup relative to the JVM.

~~~
sz4kerto
JVM start-up time is below 50 msec. Is that so slow? (Measure a simple hello
world, and you will see.) Any slowness above that comes from your code, not
the JVM.

~~~
socksy
Maybe more accurately JVM based Clojure, as opposed to node based
ClojureScript (Lumo).

------
stretchwithme
CircleCI rocks. Our tests ran almost as fast as they do on a MacBook. And
their pricing is great.

Of course, that was after trying to get shippable to work.

~~~
isaac_is_goat
> 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_...

~~~
thanksgiving
> 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 has a head start, then coming a close second is
acceptable I suppose?

To be honest, I have no idea what I am talking about and hoping to learn more.
My experience with CI is mostly with hobby projects with Gitlab CI and Travis
CI. I've only ever "used" Atlassian Bamboo at work if you can call me pushing
code to trunk/origin "using Bamboo".

~~~
tedmiston
Yes, CircleCI creates a Docker container for every run. In the CircleCI 2.0
config style it is more explicit about this behavior (one specifies the Docker
image they want to use) while in the 1.0 API, the config was more inferred /
implicit. It can get more complicated than this, but at minimum every build on
CircleCI is creating and destroying at least one container to run the unit
test suite. It can do this pretty quickly though: a barebones Python repo (1
function, 22 parameterized unit tests) for me takes ~12 seconds from startup
to teardown to displaying the completed build using 2.0 with virtual
environment caching.

~~~
thanksgiving
Sorry, I meant to ask about locally. I am still trying to figure out how to
write code in docker. It is very confusing and send like too much work to do
this locally.

I assume the disk is pretty much always the bottleneck? I mean even with
system CTL, how much memory can a rest API flask web app take right?

~~~
tedmiston
I'm not sure how it worked prior to 2.0 or if it was possibly, but you can
build locally in 2.0 ($ circleci build) which I think is just a thin wrapper
around a docker build + docker run + run unit tests (or whatever you want).

That said, you don't have to use Docker and for a small project with no
dependencies or no system level dependencies, I think it's overkill
personally, so I'd just test outside of Docker or use the new base images from
Circle.

[https://circleci.com/docs/2.0/local-
jobs/](https://circleci.com/docs/2.0/local-jobs/)

------
jpsim
This post makes no mention of the macOS part of the CircleCI infrastructure,
which is one of the trickiest parts of infrastructure IMHO. Tricky because
Apple's EULA prevents virtualizing on anything other than its hardware, never
more than 4 VMs per host, and not for commercial purposes...

~~~
jbob2000
Apple just needs to handle the build process themselves. Let me upload my app
code and you do all the hard work. It's not like I can deploy to other app
stores...

~~~
ec109685
Apple supports enterprise distribution outside the app store. Like the idea
though.

------
devy
We are using GitLab CI, and it seems majority of the features of CircleCI are
already provided in GitLab CI. Can someone with experience with CircleCI and
GitLab CI to talk about some differences?

~~~
the_common_man
Gitlab ci works best with gitlab. Circle ci is is better suited for github

~~~
tedmiston
That pretty much sums it up. I've used both on different teams and like both.
But everything in GitLab integrates so nicely that it doesn't make sense to
break out of the box IMO. With the 2.0 API that just rolled out, CircleCI has
flipped from "convention over configuration" to everything being explicit. I
find that it takes a bit longer to write the config files in 2.0 but they're
easier to read and understand what's going on because they're more explicit.

Since 2.0 just launched and they have solid example projects across languages,
it's a good time to give it a shot. It'll be easier if you've never used the
1.0 version of the product IMO.

------
tlackemann
CircleCI has been faster and easier to use than TravisCI. Their macOS builds
ran 10x faster and it only took me an hour to rewrite the config. My only
complaint is their macOS pricing is based on minutes which I was unaware of.
Ended up using 80% of my minutes this month so needed to rethink my build
strategy. Not huge, but just a consideration.

~~~
the_mitsuhiko
I find circle to build significantly slower and it can only build xcode
projects. Not impressed at all.

------
justinwp
Some of our builds are running on CircleCI but have been trying out drone for
a more container focused build. Been enjoying the flexibility and increased
speed from custom build images which are trivial to make.

~~~
clarkdave
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 docker cache is always available.

Buildkite provide a CloudFormation stack, but we just opted to run the agents
as containers via ECS to make the setup quicker and managing them easier.

~~~
robertely
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...

~~~
clarkdave
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.

------
mrmrcoleman
Main 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.

~~~
circular_logic
I think each container can have up to 8 cores. So using multiple containers to
parallelise your tests is your choice.

------
_pmf_
That's pretty impressive, given that a build typically hogs CPU as well as IO.

