Hacker News Reader

Fair enough to advocate for your project, which I btw find it very nice.

However, xml configuration is really a weak argument. It is very rare that anyone needs to touch the XML files. In fact, when someone touches those files is normally due to either a very extreme case or more commonly lack of interest in learning how the admin UI works. Jenkins lets you manage absolutely everything from the UI, from the very beginning, which is pretty convention-over-configurationish. Also Jenkins' changes control system lets you track and diff every change very quickly.

Fair. My real gripe with jenkins is the UI configuration - the XML is a bit of a sideshow. I'll restructure my post slightly, thanks.

You can track changes in Jenkins configurations?

Actually I was wrong on that one. I took for granted that you could track changes because we have a nice "Job Config History" menu option. But that is actually the job config history plugin ( https://wiki.jenkins-ci.org/display/JENKINS/JobConfigHistory... )

So, I step back on saying Jenkins lets you track main changes history. That has to be done manually I guess.

This plugin is actually really nice.

Thanks, this will help. :)

I find Jenkins UI too cluttered with a lot of stuff being hidden by default behind the "Advanced" buttons. So I stopped using Jenkins UI and migrate all my job definitions to YAML file in my source code repo. I use OpenStack Jenkins-job-builder to generate job.

Here is the list of different tools, that can be used to automate Jenkins: https://gist.github.com/lechat/6666099

> or more commonly lack of interest in learning how the admin UI works.

If this is even possible, the admin UI is not usable enough. "Man, I wouldn't have to use this ridiculous XML configuration system, if only I had the patience to slog through this UI. Alas..."

I'm another competitor in this space -- in fact more a competitor to Jenkins than CircleCI in that we don't offer CI-as-a-service (if anyone's interested the details are in my profile).

I think you're unfair to Jenkins in a couple of ways:

1) It's not as hard to set up as you make out. If you want to see what it's really like for nothing to work out of the box then head to the pre-Jenkins (then Hudson) era when CruiseControl was king (and I mean no disrespect to CC, it was a groundbreaking project). I agree, though, that the overall UX leaves plenty to be desired, and indeed this is one way we compete with Jenkins.

2) The strength of Jenkins is support for a huge range of environments and tools, with contributions in the small from a massive user base. Part of the trade off for this flexibility is some extra complexity.

I gather CircleCI approaches this space from a different angle, by narrowing focus thus making a streamlined UX a lot easier. That's a fine approach, and I wish you great luck, but it's not a way to "vanquish" Jenkins because you won't be able to satisfy most of the Jenkins user base.

Our approach is somewhere in between, and the balance is our greatest challenge. We've spent a lot of effort focused on ease of setup, and even more on ease of ongoing maintenance (especially for large build farms). I don't expect we'll ever compete with Jenkins on pure flexibility, rather I think there is room for many competitors in this space. After all, everyone should be into CI!

That seems more than a little dishonest.

Installing jenkins and adding a job that will work immediately is a matter of minutes and doesn't require you to touch any configuration file at all.

Definitely much quicker than figuring out the pricing and limitations of CircleCI.

A matter of minutes? Now who's being dishonest.

Unless you already have experience setting up a JVM stack, it's going to take you many hours.

Not really. It has a Debian/Ubuntu repository. A couple of commands and then it's literally "sudo apt-get install jenkins"

On any recent distro the following command (or equivalent) will leave you with a fully functional jenkins on port 8080:

   apt-get install jenkins

From there you open the web interface and click on 'New job'...

How you'd spend 'many hours' on that is beyond me.

The whole "hours of pain thing", first begins when you press "New job". I set up my first Jenkins build server a week ago and I spent about 10 hours googling cryptic error messages, when trying to configure the build.

So first it begins with the installation, now it begins after installation...

I have a strong feeling someone is trolling here.

Can you paste some of these 'cryptic error messages' that you were getting?

Those are two different people...

Dude these are your own words: "Installing jenkins and adding a job".

Installing Java is a matter of minutes and you probably already have it in your system.

Then you have many platform specific packages or you can just download the war and run "java -jar jenkins.war".

CI sucks... in big companies it sucks more. The unruly XML configs are a small part of the problem.

Taking two days though? Fire the engineer(s) behind the initiative. (I assume this is a one-sided sales pitch though.)

You guys have clearly hired a baller good UX/UI person and have an amazing roster of clients. Wish you all the success in the world!

Two days actually makes sense. Let's say you already have a machine, and haven't set up jenkins before. You need to install ubuntu, install jenkins, and then start to configure and figure it out as you go. Its not use friendly, so I would expect this to take most of the day.

That's without installing the databases, queues, etc, that you need. In all likelyhood, you wont have this in chef (your production box doesn't run postgres or redis or rabbit), so you're going from scratch. All it takes is one pesky configuration thing you can't figure out to have it take your entire day.

And heaven forbid if you haven't got a few years of linux admining under your belt already, in which case you can write off the rest of the week.

And don't forget to document it so that it is repeatable and then cleanup the documentation when you are done with all the configs that didn't work.

Shouldn't there be a reusable Ansible-Docker thingy somewhere?

It's not configuring jenkins that's the problem. It's all scripts it requires, build, testing, packing, deployment scripts and whatever else you want to automate.

In general trying to automate things, brings all the workflow problems out to forefront to be fixed. It makes thinking clearer.

Depending on your needs, Bitnami [0] and TurnKey Linux [1] offer preconfigured batteries-included VMs (among other options) that might lower the barrier to entry. (I'm not affiliated with either, but have enjoyed using Bitnami's stacks.)

In particular, I have found Bitnami's Jenkins stack to be helpful for quickly spinning up a prototype and focusing on Jenkins rather than than installing+configuring databases and other stuff. I think it took me about an hour to be up and running with Bitnami's Jenkins VM, including download and provisioning time. It then took me quite a bit longer to coax Jenkins into building my stuff correctly.

Installing and configuring databases and other subsystems may eventually be necessary depending on scale. For my prototyping and learning needs, I've greatly benefited by working with self-contained VMs like Bitnami's. It's an option to consider, at least.

[0] http://bitnami.com/stack/jenkins

[1] http://www.turnkeylinux.org/jenkins

"CI sucks... in big companies it sucks more. The unruly XML configs are a small part of the problem."

That has nothing to do with CI. CI is a workflow, not an implementation.

I don't know why you hate Jenkins so much but from my experience, Jenkins is better than a lot of the OSS from the installation / maintenance point of view, e.g. you can perform upgrade, restart, install plugins and most of the other tasks just using the web ui, and since it is Java, you only need a JVM and don't need to deal with stuffs like rvm, gems, passenger & nginx found in some rail projects like redmine.

2 days to configure jenkins? Yeaaaaahh suuureee...

Why doesn't Hacker News just delete obvious spam? I mean really whats the difference from this post to "buy cheap here, watches discount outlet..." Its more coherent, but other than that ;) Or how about giving it another background color and label it clearly as advertisement in case op payed not to get spamfiltered.

Not very obvious. The first time I met Jenkins, I think, it took about a day (or maybe even more) until I stopped tinkering the knobs.

Most of the time was spent not configuring it (I guess it took maybe a pair of hours or about so), but experimenting around and reading about features/use cases/examples to understand what I can do and what I can't.

Yo, I love what you guys are doing - I even interviewed with ya'll last spring - but you're overdissing Jenkins here. I can get a basic job running in a basic Jenkins instance in well under 30 minutes, for an already live Linux server w/ JRE. I don't have to configure hardly anything except for the job.

Notus Bene: Mind you, after you need to do super complicated things & especially fuss with some varieties Windows auth, Jenkins gets complicated.

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

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).

Do you support SVN? If not, why not?

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

I believe your svn needs can be worked around with some git-svn, provided they dropped the github lock-in.

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).

>>Some examples of this: scaling your CI to run more than one build at the same time is tough on Jenkins, trivial on Circle

That is not true. In Jenkins you just check "concurrent builds" in your job configuration and that's all.

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.