Untangling Jenkins • Hacker News Board

Re: Untangling Jenkins

#51

Post by piva00 » Wed, Dec 27, 2017, 1:07 PM UTC

oblio wrote: post #43

mikewhy wrote: post #17

Earlier quoted context omitted.

Another downside to Jenkins: $200/hr to learn other products do it just as well with much less overhead.

That was actually a joke since I've never done any Jenkins consulting but Jenkins, including the setup cost is waaaay cheaper than other solutions I've seen for what I used it for: distributed cron, queuing system for tasks, higher level dashboard for managers, CI server, etc.

I could tell it was a joke when you mentioned keeping backups of your main configuration instead of porting ALL of your Jenkins config to code and maintaining that in version control.

At my current job I started as a SRE for the team supporting Jenkins and other CI/CD tools for the rest of engineering (around 50+ other teams), I moved back to a SWE position but as an insight: don't run a single master Jenkins for all of your teams, make it federated (per-team/project or whatever suits your organisational structure) AND do all of Jenkins' configuration through scripts.

Never rely on backing up the old configuration (problematic in cases of rollback to previous Jenkins versions, brittle for recovery), just start it fresh every time you need to recover and re-run your provisioning scripts, that also includes NEVER maintaining jobs through the UI, only through JobDSL, JJB or Pipeline scripts.

Re: Untangling Jenkins

#52

Post by oblio » Wed, Dec 27, 2017, 3:44 PM UTC

piva00 wrote: post #51

oblio wrote: post #43

Earlier quoted context omitted.

That was actually a joke since I've never done any Jenkins consulting but Jenkins, including the setup cost is waaaay cheaper than other solutions I've seen for what I used it for: distributed cron, queuing system for tasks, higher level dashboard for managers, CI server, etc.

I could tell it was a joke when you mentioned keeping backups of your main configuration instead of porting ALL of your Jenkins config to code and maintaining that in version control. At my current job I started as a SRE for the team supporting Jenkins and other CI/CD tools for the rest of engineering (around 50+ other teams), I moved back to a SWE position but as an insight: don't run a single master Jenkins for all…

You need the team you're part of to have enough discipline for that. Not always the case. Sometimes you need to know when to cut your losses and go for the cheap, plastic, solution (i.e. backups).

Re: Untangling Jenkins

#53

Post by grogenaut » Thu, Jan 04, 2018, 4:18 PM UTC

voidr wrote: post #49

grogenaut wrote: post #9

Earlier quoted context omitted.

The point is that you get mu hich better reuse by not allowing arbitrary groovy and building up interface contracts. This is exactly like any other coding. Using groovy is akin to allowing arbitrary SQL from your web devs intead of apis (from an interface pov not security). Instead just invoke something outside of Jenkins groovy framework like maven, make, etc. Makes you much more portable and upgradable. Jenkins sho…

> Finally doing too much in Jenkins makes it impossible to test Jenkins locally, which means you can neither debug builds locally without pushing new code to build, nor can you test alterations to Jenkins itself locally which makes it much much more fragile. If you would have used Jenkins pipelines, you would know that you can debug it directly from the UI. I can make my builds hard to run locally on configuration-ba…

>If you would have used Jenkins pipelines Nice, way to start off with an ad hominem attack. Yes I'm lying to you about having used pipelines. That's what I do, I go on hacker news and lie about what I do, especially jenkins, to throw people off the scent. Seriously... if people dont know that pipelines are easily debuggable, that's a problem with the documentation, not with the person. It's also not a reason to attack people.

I have used jenkins pipelines. However I didnt use it from scratch so no, I couldn't do what you said due to all of the other issues. My point is that it does let you hang yourself, I prefer the config based systems as it's harder to hang yourself.

Your NodeJs anology is more apt but who cares you got the point. This is a discussion not a literature critique.

A dev framework to me is the type of stuff you've built up around a typical compile of a given "stack". For instance, doing ruby on rails, you're likely to have a bunch of build tooling you've built up to make that easier. I would prefer to distribute that stuff more generically and unrelated to jenkins vs some other build system, as opposed to building it all into jenkins.

As for mutating workers... you seem to be under the mistaken notion that I'm discussing the one thing you are discussing. But in general, if you have a turing complete language with complete system access like you do in the groovy, you can do anything and anything isn't always a great idea. I like the config based systems as it doesn't allow you to do anything, it allows you to do things we've deemed as good for building software. Jenkins boxes end up being shared resources in a large company so it's very difficult to audit what everyone is doing and side effects they are causing.

>Fail to see how that vague statement supports your argument.

Ok

>You can reuse the groovy code you write, which means you actually get more reuse.

You can but most people don't know how to or dont. It's a break from your typical dev loop and it's yet another framework to learn. I don't think it's effective unless you dive in and most people don't dive in. So to me it's a bad model. This is opinion.