Friday, November 18, 2016

All Things Open 2016: Additional Jenkins Comments (Part 1)

At the end of October, I gave a talk about my day job at a little conference called All Things Open. I LOVE sharing what I do, especially since I can now.  Not like I ever couldn't in the 3 letter agency way of "I work with computers". The 3 letter company I previously worked for was commercial. Not everyone gets excited about autoconfiguring rack architecture. Except maybe the Open Stack people.

Jenkins, the open source automation application, is amazing. The community is incredibly active, and it seems as if I'm constantly learning some new plugin or trick to make my pipelines go. Because the best thoughts/suggestions/witty retorts are always the ones you have while you're attending the next session in the conference, I wanted to share some of them with whoever happens to come across this space. Because I have several thoughts, I'm spreading out the love over a few posts.

First things first: repo + slides are available up on GitHub. That app is so basic... It also made me realize the Javascript/Node world is pretty much Professor Farnsworth's nanobot world. 99% guarantee it's using the embers of the old hotness.

The sample project is great for demonstrating the function of MultiBranch Pipeline, the final form of pipeline management. Sidebar: The ultimate form, automated management of an entire organization of multibranch pipelines, can only be reached by GitHub Organizations and BitBucket Teams. If you're starting from "I just want to lay down some test groovy", start with the "Pipeline" job.  A field of possibilities awaits you there

There are effectively no limits to what you can do with your Pipeline jobs. In my personal development, I use the inline script to test out ideas and quickly get going. I'll use the "from a file in your repository" option as my more permanent pipeline. I like versioning my pipeline, and have it update right after I push new code without having the extra step of logging into Jenkins to update the job.
From this... this

Working on SCM managed code is, I would argue, necessary when there are many people going in and out of a common job. In release, we not only develop Jenkins but we're heavy users too. We've been using pipelines since they came to be, and we manage the various scripts through essentially a library. The pipeline jobs in Jenkins look similar, just they use a different "flow" for actions.  This gives us all a chance to see exactly what's happening in each of our flows, do code reviews, handle versioning, backup for all the things, preventing wild wild west job modification, and pretty much any other benefits from using scm.

Some repos require digging through the layers of Troy: different mix of pipeline abilities in older scripts. We're already starting to convert to using Jenkinsfiles for running our jobs, translating the extremely common, yet subtlety customized, code flow into individual repos. This also keeps the associated helper scripts and additional tweaks with the job. The common scripts are now put in a library accessible from the individual jobs.

Of course, not everyone wants or should know the details of what happens in your jobs. That's probably the main driving force for the question above In that case, then this works too.  The peeps with teh powa admins can control whatever they need to in their repository, and jobs can chug along without others having to see how the sausage (or more appropriately for the Sidebar: beer) gets made.  Sidebar: beer pairs well with pipelines.

This longer ramble answers one question that came up during the Q&A: can I set up one repo with a common build script and use it with a combination of helper scripts to manage several different similar tasks. Yes, yes you can. We're doing it today. There are a few suggestions I'd like to make if you go that route, especially since there are so many features that didn't exist before:

  • You potentially lose the benefits of managing that common job within your scm. Changes must be applied within Jenkins itself to all your jobs. And that's a pain. </understatement>
  • CloudBees offers a Templates Plugin that really solves this problem. Check within your company to see if you have a CloudBees subscription as that will really shorten your configuration time.
  • You could possibly get around your helper script by using variables that just tell your main job which helper script to load. Make sure you have good security set up before going down this route.
I'll be experimenting with some more of these suggestions as part of just further Jenkins discovery, and will share what I find! Feel free to ask questions, and share how you've used Jenkins pipeline. I'll do some other posts with additional thoughts and reflections so stay tuned.


I'm trying to consciously only add 1 space between typed sentences because along that front the Manual of Style put up another "W" for Chicago (no pressure Bears). It's so hard after living double spaced 4-lyfe. I think it looks cramped as if everything is one run on sentence in a poem that never found its way. But hey, the people who get passionate about typography say 1 space. However, you'll pry semicolons out of my cold, dead hands.