Having used CircleCI for a trial period, I can say Jenkins is definitely the way to go. CI on a PaaS is a bit of a black box, and when things go wrong you will suffer. The only real thing CircleCI does is put some pretty CSS around what Jenkins already does. Nice try though...
As a current user of CircleCI, and as someone who set up Jenkins for general consumption at my last company, I have to echo your sentiment. With CircleCI, we have been left in the dark for more time than I care to think about due to completely oddworld (and sometimes sporadic) failures. Jenkins took me less than a day to set up (as someone who had never set it up before), and while it wasn't all smooth sailing, everyone was capable of diagnosing problems that we encountered.
To be fair to both Circle and Jenkins, between Github, Heroku and/or <insert other virtual services here>, there are a lot of 'black boxes' that have to work in concert (for us, and probably for many others out here). As the pin that ties the deployment cycle together, CI tends to draw on a lot of hate (warranted or not) from engineers trying to get their code out of the door.
I find that I am happier when I can get my hands dirty and help myself when things go awry. Software is all fun and games until a black box is standing between you and deployment.
When was your trial? Happy to hear about the suffering and what we could do better there.
We have actually spent a lot of time trying to reduce the pain and suffering from CI. Of course, you can't please everybody: trying to do that gets you Jenkins. Rather, we try to make a wonderful experience for web apps running on Linux.
Some examples of this: scaling your CI to run more than one build at the same time is tough on Jenkins, trivial on Circle. Same with splitting long builds over multiple machines. Doing either of these on jenkins is a massive pain, and most of our converts from jenkins come over at that point in trying to scale it.
Another example is that many projects will just work out of the box, with no configuration: Ruby, node and python projects in particular (also Go, scala and clojure and a subset of Java projects). But when you do need to configure, we allow you configure a very large amount. How does that differ from jenkins? Well, we try to make that configuration as simple as possible, while still providing you with as much power as you need. See some detail in https://circleci.com/docs/configuration
Lastly, in terms of preventing suffering, we have some really cool features around debugging, such as being able to SSH into our build VMs, and fantastic customer service, manned by engineers (my day is Monday, feel free to say hi: sayhi [at] circleci.com).
Don't mean to hijack the thread, but since you dropped in the shameless plug, I got a question: are you considering allowing repos outside of GitHub? I know it sounds like heresy here on HN, but f.ex. I often don't host my commercial projects there, and both Circle and Travis accept only GitHub. I mean, what's the difference where the git repo is hosted (other than UX)?
Yea, I checked out CircleCI back when the demo was making the rounds. Cool looking, but I don't use GitHub so it's kind of useless for me. I keep it on my "keep an eye on it" list, and would switch in a heartbeat if it
1. Supported non-GitHub hosted repos
2. Supported more languages (Objective-C, C++, etc)
3. Supported SVN
Its about focus, which I believe is essential for both great products and successful startups. By focussing on GitHub only (we also focus pretty much on web apps running on Linux) we are able to make a great experience with limited resources. If we had said we'll also support svn and objc and windows and iphone and embedded systems, we'd be all over the place.
I consider it like Heroku vs Amazon. You can do anything with Amazon (like on Jenkins), but with Heroku it just works (like on Circle).
I don't get it, heroku is not a github plugin, I don't see how providing a clone url on a different domain would make you unfocused. But it's your business, so good luck anyway.
The Status API, how we clone quickly, the entire signup workflow are all built around Github. We have special logic for github downtime, retries, handling 3rd party repos, collaborators, etc. For example, we dont have usernames or passwords or password resets for Circle, we just have github oauth. We don't have teams, we just mirror the github permission model. We don't verify your email: github does it.
Most importantly, when you sign up, there's a great flow. You give us oauth permission, and pick a repo (we have a list because Github) and then we can have you running tests in seconds. We automatically fiddle with Github to make that work (you dont need to add post-commit hooks or ssh keys, it just works).
