diff options
Diffstat (limited to '.html/dev/whats-wrong-with-jenkins.html')
| -rw-r--r-- | .html/dev/whats-wrong-with-jenkins.html | 172 |
1 files changed, 172 insertions, 0 deletions
diff --git a/.html/dev/whats-wrong-with-jenkins.html b/.html/dev/whats-wrong-with-jenkins.html new file mode 100644 index 0000000..1b9ab6e --- /dev/null +++ b/.html/dev/whats-wrong-with-jenkins.html @@ -0,0 +1,172 @@ +<!DOCTYPE html> +<html> +<head> + <title> + The Codex » + Something's Rotten in the State of Jenkins + </title> + + <link + rel='stylesheet' + type='text/css' + href='http://fonts.googleapis.com/css?family=Buenard:400,700&subset=latin,latin-ext'> + <link + rel="stylesheet" + type="text/css" + href="../media/css/reset.css"> + <link + rel="stylesheet" + type="text/css" + href="../media/css/grimoire.css"> +</head> +<body> + +<div id="shell"> + + <ol id="breadcrumbs"> + + <li class="crumb-0 not-last"> + + <a href="../">index</a> + + </li> + + <li class="crumb-1 not-last"> + + <a href="./">dev</a> + + </li> + + <li class="crumb-2 last"> + + whats-wrong-with-jenkins + + </li> + + </ol> + + + + <div id="article"> + <h1 id="somethings-rotten-in-the-state-of-jenkins">Something's Rotten in the State of Jenkins</h1> +<p>Automated, repeatable testing is a fairly widely-accepted cornerstone of +mature software development. Jenkins (and its predecessor, Hudson) has the +unique privilege of being both an early player in the niche and +free-as-in-beer. The blog space is littered with interesting articles about +continuous builds, automated testing, and continuous deployment, all of which +conclude on “how do we make Jenkins do it?”</p> +<p>This is unfortunate, because Jenkins has some serious problems, and I want it +to stop informing the discussion.</p> +<h2 id="theres-a-plugin-for-that">There's A Plugin For That</h2> +<p>Almost everything in the following can be addressed using one or more plugins +from Jenkins' extensive plugin repository. That's good - a build system you +can't extend is kind of screwed - but it also means that the Jenkins team +haven't felt a lot of pressure to address key problems in Jenkins proper.</p> +<p>(Plus, the plugin ecosystem is its own kind of screwed. More on that later.)</p> +<p>To be clear: being able to fix it with plugins does not make Jenkins itself +<em>good</em>. Plugins are a non-response to fundamental problems with Jenkins.</p> +<h2 id="no-granularity">No Granularity</h2> +<p>Jenkins builds are atomic: they either pass en suite, or fail en suite. Jenkins has no built-in support for recording that basic compilation succeeded, unit tests failed, but linting also succeeded.</p> +<p>You can fix this by running more builds, but then you run into problems with +...</p> +<h2 id="no-gating">No Gating</h2> +<p>... the inability to wait for multiple upstream jobs before continuing a +downstream job in a job chain. If your notional build pipeline is</p> +<ol> +<li>Compile, then</li> +<li>Lint and unit test, then</li> +<li>Publish binaries for testers/users</li> +</ol> +<p>then you need to combine the lint and unit test steps into a single build, or +tolerate occasionally publishing between zero and two copies of the same +original source tree.</p> +<h2 id="no-pipeline">No Pipeline</h2> +<p>The above are actually symptomatic of a more fundamental design problem in +Jenkins: there's no build pipeline. Jenkins is a task runner: triggers cause +tasks to run, which can cause further triggers. (Without plugins, Jenkins +can't even ensure that chains of jobs all build the same revisioins from +source control.)</p> +<p>I haven't met many projects whose build process was so simple you could treat +it as a single, pass-fail task, whose results are only interesting if the +whole thing succeeds.</p> +<h2 id="plugin-the-gap">Plugin the Gap</h2> +<p>To build a functional, non-trivial build process on top of Jenkins, you will +inevitably need plugins: plugins for source control, plugins for +notification, plugins for managing build steps, plugins for managing various +language runtimes, you name it.</p> +<p>The plugin ecosystem is run on an entirely volunteer basis, and anyone can +get a new plugin into the official plugin registry. This is good, in as much +as the barrier to entry <em>should</em> be low and people <em>should</em> be encouraged to +scratch itches, but it also means that the plugin registry is a swamp of +sporadically-maintained one-offs with inconsistent interfaces.</p> +<p>(Worse, even some <em>core</em> plugins have serious maintenance deficits: have a +look at how long +<a href="https://issues.jenkins-ci.org/browse/JENKINS-20767">JENKINS-20767</a> was open. +How many Jenkins users use Git?)</p> +<h2 id="the-plugin-api">The Plugin API</h2> +<p>The plugin API also, critically, locks Jenkins into some internal design +problems. The sheer number of plugins, and the sheer number of maintainers, +effectively prevents any major refactoring of Jenkins from making progress. +Breaking poorly-maintained plugins inevitably pisses off the users who were, +quite happily, using whatever they'd cooked up, but with the maintainership +of plugins so spread out and so sporadic, there's no easy way for the Jenkins +team to, for example, break up the <a href="https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/model/Jenkins.java">4,000-line <code>Jenkins</code> class</a>.</p> +<h2 id="what-is-to-be-done">What Is To Be Done</h2> +<p>Jenkins is great and I'm glad it exists. Jenkins moved the state of the art +for build servers forward very effectively, and successfully out-competed +more carefully-designed offerings that were not, in fact, better: +<a href="http://continuum.apache.org">Continuum</a> is more or less abandoned, and when +was the last time you saw a +<a href="http://cruisecontrol.sourceforge.net">CruiseControl</a> (caution: SourceForge) +install?</p> +<p>It's interesting to compare the state of usability in, eg., Jenkins, to the +state of usability in some paid-product build systems +(<a href="https://www.atlassian.com/software/bamboo">Bamboo</a> and +<a href="https://www.jetbrains.com/teamcity/">TeamCity</a> for example) on the above +points, as well as looking at the growing number of hosted build systems +(<a href="https://travis-ci.org">TravisCI</a>, <a href="https://magnum-ci.com">MagnumCI</a>) for +ideas. A number of folks have also written insightful musings on what they +want to see in the next CI tool: Susan Potter's +<a href="https://github.com/mbbx6spp/carson">Carson</a> includes an interesting +motivating metaphor (if you're going to use butlers, why not use the whole +butler mileu?) and some good observations on how Jenkins lets us all down, +for example.</p> +<p>I think it's time to put Jenkins to bed and write its successor.</p> + </div> + + + +<div id="comments"> +<div id="disqus_thread"></div> +<script type="text/javascript"> + /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */ + var disqus_shortname = 'grimoire'; // required: replace example with your forum shortname + + /* * * DON'T EDIT BELOW THIS LINE * * */ + (function() { + var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; + dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js'; + (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); + })(); +</script> +<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript> +<a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a> +</div> + + + + <div id="footer"> + <p> + + The Codex — + + Powered by <a href="http://markdoc.org/">Markdoc</a>. + +<a href="https://bitbucket.org/ojacobson/grimoire.ca/src/master/wiki/dev/whats-wrong-with-jenkins.md">See this page on Bitbucket</a> (<a href="https://bitbucket.org/ojacobson/grimoire.ca/history-node/master/wiki/dev/whats-wrong-with-jenkins.md">history</a>). + + </p> + </div> + +</div> +</body> +</html>
\ No newline at end of file |