Now Reading
Life is Too Brief for Jenkins

Life is Too Brief for Jenkins

2023-12-03 08:40:36

About 9 months in the past, I requested a switch to the workforce engaged on the corporate’s CI tooling. In my judgement, CI was a serious productiveness blocker for the entire group, and I hoped I might have the ability to assist enhance it and make a broad, optimistic impression.

At the moment, CI was in Jenkins 1, which had three main issues:

  1. All people’s CI pipeline was described in textual content packing containers within the Jenkins UI, which meant they weren’t model managed, discoverable, and enhancing/testing new configurations was a troublesome expertise.

  2. The online interface was dated and ugly to make use of.

  3. Builders had little management over the setting by which their jobs ran, as a result of the VMs working as Jenkins nodes have been centrally managed.

My workforce thought-about two choices.

Possibility 1: Change instruments

The pinnacle of SRE championed Gitlab CI. I resisted this concept as a result of I, the comparatively inexperienced supervisor of a nascent workforce, was daunted by the prospect of attempting to supplant Jenkins, Github, and JIRA abruptly.

On a earlier workforce I had used Concourse CI to some extent, however I wasn’t actually blown away by the expertise. Travis and Circle have been talked about. I used to be a idiot. I ought to have dedicated to significantly researching a number of the contenders and making a extra knowledgeable resolution, however I lacked the willpower and the discernment.

Possibility 2: Improve to Jenkins 2

On the face of it, Jenkins 2 appeared to fulfill all our wants. It:

  1. Helps defining your CI job as a “declarative pipeline” that may reside as a Jenkinsfile within the root of your repository. Hooray configuration as code!

  2. Boasts a UX facelift referred to as “Blue Ocean” that appears extra trendy.

  3. Permits pipelines to request to be run on a docker “agent”, which lets software builders management the setting on which their job is run by specifying a Docker picture or Dockerfile.

A Taxonomy of Errors

The worst errors are available two distinct flavors: catastrophic and insidious.

A catastrophic mistake is like triggering an outage, or deleting manufacturing knowledge. The second you understand what you’ve performed is the worst single second in your profession. Your coronary heart kilos in your chest. Is that this a nightmare? Perhaps in a second, you’ll get up? No, it’s actual. Hopefully, you’ve acquired a wholesome tradition at work, and also you desperately describe the state of affairs to your teammates, who rally to your facet. Any individual with a cool head thinks of some method to make the very best of issues, and by some means – perhaps that night time, perhaps the subsequent day – you make it by. Issues return to regular. You write a postmortem, rely your losses, and return to work – rather less harmless, and somewhat wiser.

An insidious mistake, in contrast, doesn’t reveal itself in a second. It makes you undergo somewhat bit right here, and somewhat bit there, till someday you get up and also you understand that there’s a gaping gap the place your humanity was once. You’re a depressing husk of a person, with cruelty in your lips and bile in your coronary heart. You continue to greet your colleagues with that jolly smile of yours – however the sweetness in your smile is the saccharine of cynicism, not the honeyed optimism because it was within the days earlier than, when life was cheerful and your burden was gentle. The sunshine in your eyes was once the hope for a greater tomorrow. Now it’s the glint of insanity.

What’s incorrect with Jenkins

Selecting Jenkins was the insidious sort of mistake. Warning – I’m going to rant for a lot of, many paragraphs. My recommendation is to skim.

The worst factor about Jenkins is that it really works. It might probably meet your wants. With a liiittle extra effort, or by adopting sliiiightly decrease requirements, or with a liiiiitle extra tolerance for ache, you possibly can all the time get Jenkins to do aaaaalmost what you need it to. However let’s speak specifics. Jenkins options:

Excessive indirection between you and the execution of your code.

For me, the majority of the particular work of a CI pipeline takes the type of shell instructions. are usually executed inside shell instructions. In Jenkins pipeline, there’s a ‘sh’ “step” that executes the shell. For instance

JenkinsPipelineUnit which is an excellent thought – it enables you to write unit checks in opposition to your Jenkins Pipeline, and offers you an interface for mocking varied Jenkins issues. However there are two issues:

  1. As famous within the README, Groovy doesn’t run the identical means on Jenkins because it does in your unit check, as a result of the groovy DSL is “serialized” by Jenkins earlier than operating.
  2. “Declarative” pipelines are not supported – an enormous drawback for us, since that’s how we’ve carried out all our stuff, because it appeared to be the latest and most trendy factor to be doing.

So principally, that’s an enormous bust. Particularly since we weren’t a Java store. My workforce was barely in a position to sort of piece this collectively as a result of it’s our job to work on the CI system, however there’s completely no means that any of the PHP/Javascript/Golang/Python software builders who want to write down pipelines will have the ability to obtain Gradle, determine they should run gradle init, set up the pipeline unit testing library, determine the right method to initialize the “PipelineTestHelper”.

So we’re principally resigned to the workflow of operating shell instructions outlined in strategies utilized by a DSL embedded in groovy transmitted to the CI grasp node, serialized and handed to a CI employee node and executed there.

There’s a “replay script” characteristic that permits you to edit your pipeline proper within the net interface, which helps reduce down on the suggestions time somewhat bit in the event you don’t care about model controlling your adjustments or with the ability to use your individual editor/instruments. I personally am not prepared to make that sacrifice.

TL;DR, the suggestions loop sucks. You’ll by no means have the ability to successfully check any of the code operating in your pipeline. Your finest wager is to construct all of it completely in Bash, construct your individual mechanism for testing it and sharing performance. The flexibility to write down Groovy shared libraries is a entice and leads solely to distress.

Low degree of discoverability

A number of performance that Jenkins has within the net UI – particularly the performance that comes by plugins – can be attainable to outline in pipelines, however the means for doing this isn’t well-documented. For instance, there’s this plugin that lets you “throttle” a job in order that a number of jobs don’t hearth without delay. that you would be able to see contained in the UI. After most likely half a day of Googling, trial and error, and because of a stroke of luck, I found out that I might accomplish what I needed by placing the next in my Jenkinsfile:

See Also

Source Link

What's Your Reaction?
In Love
Not Sure
View Comments (0)

Leave a Reply

Your email address will not be published.

2022 Blinking Robots.
WordPress by Doejo

Scroll To Top