[gkop]

Eh, I'm sure there are many things Jenkins is OK at, but it's not that great of build server.

The Multi-Configuration Project abstraction (IE build matrices) is clunky and the plugin ecosystem doesn't respect it well (eg. the Gerrit plugin is extremely popular but very brittle here). So you wind up with O(n) projects anyway and still needing to copy and paste configuration among them.

Also Jenkins configuration itself is pretty nuts - settings splattered all over the web UI, backed by XML - compared to the simplicity of modern tools like Travis (which uses YAML).

And Jenkins' UI I would definitely categorize as typically-poor open source UI, having evolved and grown more complex over many years with no strong guiding vision.

[gtaylor]

We were in the same boat as we moved towards a more Dockerized production environment on Kubernetes. There is a great Jenkins+Kubernetes whitepaper detailing how to string all of the various plugins together, check all of the right boxes, fill all of the right fields in. But it was apparent that the setup and maintenance costs were going to be higher than we wanted. And nobody outside of the engineering group would probably be able to figure out how to use the thing (we have a lot of other teams writing code that aren't "engineering" teams).

Right before I was about to give up, I found Drone: http://try.drone.io/ (GitHub: https://github.com/drone/drone)

With Drone, builds are done within Docker containers. Cool enough, nothing super special there. The real magic is that all of the plugins (http://addons.drone.io/) themselves are also ran in Docker containers. So we can write plugins in whatever language we want, they can be pinned to specific tags or auto-upgraded at build time.

That and the setup process was basically "run this Docker image, pass in some env vars". The UI, while still very basic is easy enough for our other teams to use, and the small but growing community is very receptive to feedback and pull requests.

Check it out if you aren't opposed to a Docker-heavy build system. If you are running a Kubernetes setup like us, here are some starter manifests for you (http://gc-taylor.com/blog/2015/10/27/example-drone-ci-kubern...)

[JulianWasTaken]

I agree with all this. Unfortunately I haven't found anything less bad :(

[VoiceOfWisdom]

Jenkins + the Job DSL Plugin [0] has been amazing. We don't do any configuration in the web interface, instead everything lives in a groovy file on BitBucket. Every time we push a change Jenkins grabs it and auto runs the groovy file, regenerating all of our jobs. We have it set up so that a job is created for every branch in our repo, so much easier to work with. All a developer has to do to get his branch building is push it to the repo.

[0] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin

[vorg]

You only need recognition-memory to use Web and GUI interfaces, whereas you need recall-memory to use command line interfaces and scripts, which is far more difficult. That's why clicking in a Web GUI or graphical XML-generator replaced scripting. You need a lot of previous information in your memory for recall to write stuff like the following example taken from your linked page:

  def project = 'quidryan/aws-sdk-test'
  def branchApi = new URL("https://api.github.com/repos/${project}/branches")
  def branches = new groovy.json.JsonSlurper().parse(branchApi.newReader())
  branches.each {
    def branchName = it.name
    job {
        name "${project}-${branchName}".replaceAll('/','-')
        scm {
            git("git://github.com/${project}.git", branchName)
        }
        steps {
            maven("test -Dproject.name=${project}/${branchName}")
        }
    }
  }

The vocabulary and grammar in that script is quite complicated and people would rather be presented with the options for clicking on a web page. But perhaps you're promoting a particular software product?

[dripton]

GUIs are more discoverable than command lines. Text files are easier to save in version control. So it's common to have a system where the GUI hooks new users, but they eventually have enough configuration in it that the GUI is no longer a reasonable way to control it all, and they need a way to extract the information in a reasonable format. Hence the reason several Jenkins plugins have evolved to do that.

[e28eta]

I also used JobDSL, and thought it worked pretty well. I don't think my teammates agreed, they seemed to just want to change things in the UI and this was just something getting in the way of their work. Some were willing to learn it, others weren't interested.

I think the new Jenkinsfile approach looks very promising: http://jenkins-ci.org/content/pipeline-code-multibranch-work...

[btd]

We do similar thing but with workflow plugins.

[avtar]

At work we use Jenkins Job Builder http://docs.openstack.org/infra/jenkins-job-builder/#content... to maintain jobs using JSON or YAML files. As a result we rarely have to deal with the Jenkins web UI and that's alright :)

[RickHull]

Jenkins Job Builder is, IME, the only way to keep complex Jenkins configs sane. Did you know that Jenkins is constantly rewriting its own XML config? We've had Jenkins itself corrupt its own config (with some combination of active plugins).

Keeping your configs in YAML in source control is such a win. Not a fan of Jenkins, BTW.

[slavik81]

Every time I install Jenkins, I install the thinBackup plugin. Losing your configuration is way too common, but it's easy to restore.

[gvalkov]

In line with the other suggestions, there is also jenkins-autojobs [1] (disclaimer: I wrote it). It's a set of scripts that listen for changes in a git|hg|svn repository and create|update jobs from template jobs and the rules defined in a yaml config file [2].

[1] https://github.com/gvalkov/jenkins-autojobs [2] http://jenkins-autojobs.readthedocs.org/en/latest/examples.h...

[PebblesHD]

We use this to generate builds from our (many, many) feature branches, its amazingly useful, bravo!

[falsedan]

Using Job DSL + Jenkins Job Builder here, trying to move as much stuff off Jenkins as possible.

[solipsism]

Have to second all of this. There plugin ecosystem looks full but the vast majority of plugins are unsupported, qality varies enormously without any good way to judge it, and god help you if you want to mix and match plugins which weren't made to work together.

The configuration is hostile to separation of concerns. The configuration of your remote build nodes goes in the same XML as the configuration that groups your jobs into "views" on the front end.

I could go on. I don't think I'd build anything complex with Jenkins again. Id prefer to build a job system from scratch, honestly.

[technion]

     the Gerrit plugin 

As far as I'm aware, none of the alternatives people have recommended actually have Gerrit plugins at all, which is a strong point for Jenkins.

There are projects out there with workflows where people submit to Github so the CI can run, then it gets pulled into Gerrit for code review on a website with no visibility into the result of that CI.

I'd love to move all code review to Gerrit but I'd need to see something disrupt this space first.

[gkop]

Except Gerrit's not really all that great either! It just looks good when everything else has been dumbed down to parity with GitHub.

This start up seems like they are trying to sort of package and iterate on the value and power of Gerrit: https://www.gitcolony.com

[technion]

I literally came across this just now:

https://github.com/google/git-appraise

Although it may well be a decent Gerrit alternative - it still talks about interfacing with Jenkins.

[fierarul]

> compared to the simplicity of modern tools like Travis (which uses YAML).

But is Travis really a tool or just a service?

Having just learned of Travis on this thread, I can't seem to find its source code.

Somebody else mentioned Drone (https://github.com/drone/drone ) which could be a proper Jenkins replacement.

[notnarb]

> Having just learned of Travis on this thread, I can't seem to find its source code.

https://github.com/travis-ci/travis-ci

I don't think there's a quick and easy way to set up your local version of Travis, but it does seem possible.

> But is Travis really a tool or just a service?

I would certainly argue it's more on the 'service' end of things. If I had to guess, most people who find hosting their code on Github acceptable (Travis only works with Github at the moment) also find using the Travis web service acceptable as well so there isn't a lot of incentive to use Travis as a locally installed tool rather than using their as-a-service offering.