5 ms·

The skin is really nice. I'm a real jenkins hater (one of the reasons I started https://circleci.com https://circleci.com) and while I think this makes Jenkins

by pbiggar 13y ago

The skin is really nice. I'm a real jenkins hater (one of the reasons I started https://circleci.com https://circleci.com) and while I think this makes Jenkins look really nice, I also think a superficial change like this doesn't really solve the major usability problems that jenkins has. There's a huge amount wrong with Jenkins. My major gripe is that the world today has moved very much to "convention over configuration", also known as "usability". But Jenkins is firmly stuck behind. It's not wrong to say that nothing works out of the box, and you have to configure every little thing. CircleCI customers have told me they've literally spent 2 days configuring a jenkins box to even get it working, and are glad to be rid of it. One example of jenkins' backwardness is a post from the Jenkins lead last week: https://news.ycombinator.com/item?id=6434194 https://news.ycombinator.com/item?id=6434194. Actual quote: "The literate plugin adds an Action to all Free-style projects that allows exporting these XML configuration snippets in a .zip file for unpacking into your project's source control." I don't mean to hate on this, just jenkins. This design is a real improvement, one that Jenkins has been unable to do in the entire 10 years it's been in existence. [disclaimer: obviously I have a massive massive bias against jenkins, as part of CircleCIs mission is vanquish it and its awful usability]

mpermar 13y ago
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.
- pbiggar 13y ago
  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.
- echohack 13y ago
  You can track changes in Jenkins configurations?
  - mpermar 13y ago
    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+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.
    - echohack 13y ago
      This plugin is actually really nice. Thanks, this will help. :)
- drunkenfly 13y ago
  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 https://gist.github.com/lechat/6666099
- icambron 13y ago
  > 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..."
austinheap 13y ago
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!
- pbiggar 13y ago
  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.
  - josephlord 13y ago
    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.
    - qznc 13y ago
      Shouldn't there be a reusable Ansible-Docker thingy somewhere?
  - UK-AL 13y ago
    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.
  - 13y ago
eulerphi 13y ago
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...
- pbiggar 13y ago
  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 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).
  - lobotryas 13y ago
    Do you support SVN? If not, why not?
  - zalew 13y ago
    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)?
deleted 13y ago
[deleted]
rlx0x 13y ago
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.
- drdaeman 13y ago
  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.
moe 13y ago
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.
- Kudos 13y ago
  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.
  - phaemon 13y ago
    Not really. It has a Debian/Ubuntu repository. A couple of commands and then it's literally "sudo apt-get install jenkins"
  - moe 13y ago
    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.
    - Sammi 13y ago
      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.
      - moe 13y ago
        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?
tszming 13y ago
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.
jsankey 13y ago
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!
pnathan 13y ago
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.

by pbiggar 13y ago

mpermar 13y ago

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.

pbiggar 13y ago
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.
echohack 13y ago
You can track changes in Jenkins configurations?
- mpermar 13y ago
  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+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.
  - echohack 13y ago
    This plugin is actually really nice. Thanks, this will help. :)
drunkenfly 13y ago
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 https://gist.github.com/lechat/6666099
icambron 13y ago
> 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..."

austinheap 13y ago

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!

pbiggar 13y ago
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.
- josephlord 13y ago
  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.
  - qznc 13y ago
    Shouldn't there be a reusable Ansible-Docker thingy somewhere?
- UK-AL 13y ago
  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.
- 13y ago

eulerphi 13y ago

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

pbiggar 13y ago
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 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).
- lobotryas 13y ago
  Do you support SVN? If not, why not?
- zalew 13y ago
  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)?

deleted 13y ago

[deleted]

rlx0x 13y ago

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.

drdaeman 13y ago
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.

moe 13y ago

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.

Kudos 13y ago
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.
- phaemon 13y ago
  Not really. It has a Debian/Ubuntu repository. A couple of commands and then it's literally "sudo apt-get install jenkins"
- moe 13y ago
  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.
  - Sammi 13y ago
    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.
    - moe 13y ago
      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?

tszming 13y ago

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.

jsankey 13y ago

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!

pnathan 13y ago

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.