[periram]

Scale, Complexity, Job Specialization, Organizational or Business needs blah blah.

Let me explain.

Imagine you have a team that grows from say 4 to 40 over time. All the initial programmers, business managers etc. have left. One fine day, you get a call from the client saying "The feed has not arrived today, fix it in the next 2 hours or we are going elsewhere (or can you please please please fix it ASAP) ..."

What do you do? How do you prevent this from happening in the first place? What procedures / software do you need to have in place to even know what went wrong etc.

Now let me give examples that these tools help you handle.

1. You need to view all the jobs that run on a daily basis across 400 of your servers. 2. You want to make sure that no changes to anything in production can happen without at least 1 more programmer and 1 more business person signing off on it. 3. A job / script fails partially, how do you assess the impact and move forward (you are not even aware of the existence of this script). 4. You have a backup script / job that needs to run on demand. You want to let your support folks run it or even the business folks, without any programmer intervention (you don't want to get a call every time someone in Japan wants to run this report).

Coming to CI/CD systems, some of their goals are

A. Codify the knowledge into scripts / configs and do not rely in tribal knowledge. B. Ensure that your code is always in a "buildable" state with the new changes (i.e. don't even let bad code in) C. When a build fails, notify the programmers who introduced the bug immediately D. Once a build is complete, send it to other systems for stress testing. ...

Yeah large businesses can have very intricate and complex needs. They rely on generic and configurable software (proven and tested by other large organizations) to meet their operational needs. Also, given that you can hire people that are proficient in these tools, you can focus on the business needs rather then reinventing these tools.

[hawski]

My problem with Jenkins is that it very often leads to a pile of Groovy, that no one really understands and then some things can be only done through Jenkins instead of a developer's machine for example. That's also one of the reasons behind all those YAML-CI/CD configs that are trendy today, which (besides using YAML) I fully agree with. Also I hate that Jenkins pushes secrets through environmental flags.

I understand that for most companies they post a job offer with Jenkins as one of keyword requirements and they are mostly done. That is probably much more important than any actual utility of the tool beyond tens or hundreds of thousands of lines of Groovy that someone has to maintain.

[marcosdumay]

Yeah, that's the answer (it's a shame it's currently so low), but I don't think it's in terms the OP will be able to relate to. I'm sure he can achieve all of those examples already.

So I'll try to refine it.

The main reason an organization uses Jenkins or Chief instead of in-house code is because they can just post job positions requiring knowledge on Jenkins or Chief, instead of minutely describing the person's tasks and training newcomers on their internal tools.

So, yeah, those tools do lots of desirable things. And slightly simplify a huge number of tasks. But the main reason one won't find a job without some experience with them is that they act a lot like competence standards on the job market.

And yeah, for a job seeker it does look a lot like they are bullshit. (And they often are - Jenkins and Chief not so much, but others are a lot.) The OP's question is a lot like "why should I learn standard calculus notation if I can calculate everything just fine on my own notation?", and if you replace that with stuff like type theory you will find people actually asking that question. The answer is always the same, it's because you need it to communicate with other people.

[pixl97]

>it's because you need it to communicate with other people.

Yep. Chances are if they use Jenkins, they'll have some vendor plugins for tools they use. Jenkins will download xml/json from the one plugin and upload it to another. Now those systems are coupled via a format and a set of behaviors around it. For a huge portion of corporate users those plugins remove a huge chunk of work they'd have to do internally, and instead of writing something from scratch, they can extend what is already there.

[jumbojax]

Your calculus analogy has me thinking that I may just haven't encountered some pain points where being able to apply certain things that will improve my quality of work. Especially in regards of being a better communicator to be more effective team member, and employee. I also tend to work in silo'd situations.

I mean, I always encounter problems at work, just not the right ones to get me to where I want to be today.

And where I'm in a situation where I'm free to do side projects, it doesn't feel better. I can't effectively come up with new problem scenarios unless they resemble something I encountered in the past.