Square open sources Kochiku
corner.squareup.com
corner.squareup.com
Except since it's in the cloud, you don't need to own 10 Mac minis to make this happen. And if you decide you want to split it 20 ways, not 10, you can do that in about 2 clicks.
[disclaimer: I work at https://circleci.com, if that wasn't already obvious]
I am sure CircleCI takes security very seriously but it also nice (and a requirement for certain companies) that with a self hosted CI server, that your source code does not leave the company.
Not looking for a flame war - just curious to get different perspectives.
edit: rephrase
For Team City, here's the cost breakdown:
TeamCity Enterprise = $1,999
229 Build agents @ $299/each = $68,741
Total yearly license cost ~ $70K
This doesn't include the time that a team of developers will spend configuring the build and babysitting it during through the early growing pains of adopting a CI system. Also you'll probably still need a build/release engineering team to manage the server when you have a team of 100+ devs like Square does.
When you add it all up, building a custom CI setup makes a lot of sense. And I'm sure they grew it over time, with an initial version that was usable being completed in just a few months. What they've open sourced is the end result of spending that time.
When you really adopt testing as part of your culture, CI becomes totally critical so engineering should spend the time to make it a solid and viable solution.
In general we probably restart executor machines quite often just due to the above issues alone.
Also our Devops folks have complained about the lack of automation around Jenkins. If they could monitor it better, we could probably be a lot more proactive about dealing with our problems around it.
If you're looking at CI for your next project, I would look at either a hosted solution like CircleCI or TravisCI Pro. Don't jump straight to self-hosted CI until you outgrow these solutions.
So that's one employee you don't have to hire. I was on a team of 4 that, among other responsibilities, managed several TeamCity instances, all of them pretty large.
Generally speaking, once it was up and running, it was pretty low overhead and easy to automate. So I think it really is worth thinking hard about the cost before people dive in and roll their own solutions.
And there's always the argument of: instead of building your own, why not work to improve an existing OSS solution?
This unfortunately has not been my experience with off-the-shelf CI solutions (open source or otherwise). Of course in all instances, we were writing a lot of new code and continuously enhancing old code so the projects under CI were very active. We dealt with CI systems being overloaded, builds breaking for cryptic environment setup reasons, and just an overall slowness due to memory leaks that were hard to diagnose and only occurred in the CI environments.
In the smaller teams, one engineer would essentially become "the build guy" that would babysit the CI system. In larger teams, this became a function of a Configuration/Release management team. In all cases, CI was a regular pain point unless there a lot of customization done over a long period of time.
At the surface level, a custom CI solution wouldn't take long to write. A simple poller to check version control, a script to build, and some basic notifications could probably be hacked together quickly and iterated on over time.
Yes, there's a lot of common patterns that can be factored into a library/system, but the little details will end up biting you at the end.
There's a cool tutorial on using Dockerfiles at http://www.docker.io/learn/dockerfile/