4 ms·

Interesting, isn't Jenkins mostly used for internal builds? I have a hard time imagining using it for things like marketing email cron jobs.

• humbleMouse 8y ago
  The beauty of jenkins is that you can use it for pretty much anything.
  • sanderjd 8y ago
    I tend to feel the opposite about things you can use for pretty much anything. I much prefer tools that are good for a single thing. I really disliked maintaining a Jenkins instance awhile back; maybe this "jack of all trades" ethos is part of the reason I felt that way.
    • brightball 8y ago
      I tend to prefer simplified stack, especially for tools that don't need to be touched very often.
      • sanderjd 8y ago
        I can't tell: are you saying that using Jenkins results in the simplified stack you prefer? If so, I don't agree; I think Jenkins is a very un-simple way to run from jobs.
        • brightball 8y ago
          When I say simplified stack I mean fewer tools that must be learned and managed by people. Jenkins simplifies in that way.
          • sanderjd 8y ago
            Interesting. I still don't see it that way. It seems less like a single tool when used in this way than multiple tools running alongside one another. Different strokes for different folks I suppose!
• flukus 8y ago
  A quick look at the front page (https://jenkins.io/ https://jenkins.io/) suggests this is still the focus: "The leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying and automating any project.". I think this is a case of everything looking like a nail to someone with a hammer. Just because you need a solution for scheduling and jenkins does scheduling doesn't make it the right tool for the job. Hopefully everyone recommending it is at least running separate instances for production environments? Some (thankfully) former colleagues of mine had our build server running production jobs...
• brightball 8y ago
  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.