Jenkins is just a job running tool. It runs the job, logs output and tracks success or failure by exit code. Also has very flexible and granular permissions. B

Jenkins is just a job running tool. It runs the job, logs output and tracks success or failure by exit code. Also has very flexible and granular permissions. Builds are just another job, usually triggered by a web hook after a git commit or periodic polling. At my last job, we took cron jobs that were spread across 27 servers that we're really well monitored and moved them to Jenkins. The server SSH'd into the boxes (where necessary) ran the jobs, alerted us if there was a problem in Slack and we could use the tracked logs to find out exactly what happened. Really helpful. Plus the cron scheduler has an alternative to picking a specific time to run by deferring to Jenkins based on other things that are running and the time it historically takes to run the job. So instead of a bunch of jobs running at 3am you can set a job to run at [1-5]H and it will run sometime between 1-5am as best determined by Jenkins. You can also trigger other jobs following the success (or failure) of another. For example, we used to have a daily digest that ran at the same time everyday and backed up our workers for a couple of hours. Instead, we created worker servers that only listened to that specific queue and scheduled a Jenkins job to start & update however many we needed, then after it was successful to trigger the digest jobs. Later in the evening, it was scheduled to scale down. Just having all the jobs in one place with job specific log rotation rules and success tracking was extremely helpful. It wasn't pretty...but it worked really, really well.