
Improving maintenance of your Jenkins(file) pipelines - cappuccinos
https://robertnorthard.com/improving-maintenance-jenkins-pipelines/
======
raziel2p
Rather than coupling your abstractions to Jenkins/Jenkinsfile/Groovy, I strive
to put all commands ran from CI in a `Makefile` or something similar. Ideally,
a Jenkins step/stage is a single shell command just with the correct
environment variables set. This makes it super easy to reproduce locally,
switching to another CI tool is much easier, and your Jenkinsfiles are 20% of
the length and only focuses on things directly related to the CI tool itself:
parallelization, cleanup, notifications...

~~~
xyzzy_plugh
You should definitely keep your Jenkins steps around a single command, like
executing a Makefile as you suggest. The problem is maintaining the job
configuration itself.

I've seen some places configure Jenkins jobs for a project in the repo itself,
so running a specific type of build depends on it being defined in that
revision of the repo you're using.

~~~
peterwwillis
And this is why Jenkins is horrible. You have a Jenkinsfile, which describes
jobs in code, but... you need to create a job... to use those other jobs...
and there's no simple, officially supported way to do that as code.

There are 4 _basic_ ways to manage the initial job configuration: By Hand,
Save The XML File, JCasC, and Groovy init files. JCasC is of course the most
ideal, but also the least intuitive, and requires further server setup.
Putting a Groovy file in an init directory is the most straightforward way,
using code. And if the Jenkins server is already running, you need a specific
interaction with some API call to actually update the job in the running
server.

You can also do more horrible things, like Jenkins Job Builder, but I think
making someone manage that is against the Geneva Conventions.

~~~
paulddraper
I haven't used Jenkins in 2 years, but before that I used the Groovy DSL
plugin.

A job that would run that and create the other jobs.

Incidentally, a similar (but native and more streamlined) approach is taken by
Buildkite: job that processes a DSL that then generates other jobs (could even
be recursive if you like that sort of thing) [1]

[1] [https://buildkite.com](https://buildkite.com)

~~~
peterwwillis
I know that in some cases that's the best solution to a problem, but I try
hard to stay away from generative processes. There's a raft of complexity
issues that arises from the need to reproduce exactly the same behavior and
results, and usually you're introducing several new layers of complexity (a
DSL, a job to process it, jobs generated from it, actions taken by those jobs,
the input and output of each process... versus one giant static job with
minimal variability).

~~~
paulddraper
It was certainly unpleasantly complicated.

------
redact207
I've used Jenkins in a few places, right back from when it was Hudson. Back
then I was amazed at the concept of CI in general so it was pretty great.

Over the years I've worked with most of the major players, most recently
Gitlab CI. The one thing that makes it hard to go back to Jenkins is the poor
quality of the plugin ecosystem. So many are abandoned or buggy that any
upgrade comes with a breath and a prayer.

I'm probably gone for good. Appreciate everything they did for the industry
but there are more robust choices around.

~~~
sytse
What can you do with Jenkins and not GitLab CI that made you go back to
Jenkins?

~~~
mcny
> The one thing that makes it hard to go back to Jenkins is the poor quality
> of the plugin ecosystem.

I don't think they went back to Jenkins.

------
lewich
We have great experience with this!

Developed shared libs that serve full enterprise organization and do complex
deployments. If project follow same rules, it is easy to encapsulate logic
into shared lib and have jenkinsfile to call it with few params.

e.g. Jenkinsfile ``` @Library('common-libraries') _ deploy(product: 'xyz',
environment: 'exyz') ```

Then, updates in shared lib propagate to all projects.

~~~
pintxo
Same here. All deployment and build is provided by one library. Made it
exceptionally easy to change the deployment model and update things because of
changes in the build environment.

------
outime
Nowadays I actively avoid Jenkins for almost everything after seeing it _fail_
in companies of different sizes (mostly medium/big ones).

Not that Jenkins itself is bad but keeping the base and plugins up-to-date is
really painful. There are a lot of plugins, yes, but many are basically
inactive or poorly written (some are really good tho).

The good thing is that there are some alternatives to Jenkins, even very good
ones if you have money to spend.

------
humbleMouse
I don't understand the jenkins hate in the comments. It's very flexible, and
if you limit your plugin use you can use it to do pretty much anything you
want.

It's also easy to run locally despite what some people have said in the
comments. You can literally download a war file and run it with java -jar
jenkins.war.

Jenkins is powerful, flexible, and easy to set up. Just avoid most plugins and
run your own Groovy/python/shell scripts. Easy peasy.

Also - what are people running in place of jenkins? The only tech I've seen
mentioned is gitlab.

~~~
0xEFF
Modern CI easily loads the pipeline definition from the source branch.

Getting Jenkins to load a pipeline definition from the source branch is
extremely complex, so much so that I’ve yet to see it done well.

------
infecto
Jenkins is bad. I have the displeasure of using it for the first time in my
current role and I find that its too complicated and abstracted for the 90%. I
am sure its great for complex pipelines but for just the 90% of CI/CD
pipelines I just do not grok it well. Perhaps I was spoiled with managed
solutions like CircleCI?

------
tn890
Does anyone still use Jenkins willingly?

~~~
lewich
what is your problem with it? :) It is usually not the tool bad, but ppl using
it can't do it right.

~~~
zelos
Not the OP, but I’m wary about implementing build logic in a form that’s only
executable on a server. Pipelines are one step better than the old style build
configuration, but still inferior to just having the whole build/test/release
cycle defined in scripts in the branch which can be run anywhere.

~~~
M3t0r
We have started using Makefiles for this. Our Jenkinsfiles are only used for
the orchestration and reporting. All our applications can be build, tested,
and released by our employees on their machines. Works great for us!

------
oracle2025
But how to retrigger all jobs that are loading a plugin, when the plugin is
updated?

