At my company, we have a quagmire of disparate cron jobs (on multiple systems) and manually kicked off processes which keep our business functioning that is a result of years of expedient development and subsequent neglect.Someday, we will need to come up with a more centralized solution for obvious reasons.One thought that we have been kicking around is to use our Continuous Integration software (Jenkins) to run these processes, which seems logical.My question is: Are other companies doing this? Is this a generally accepted practice? Doesn't this conflict with the definition of a CI tool implicit in its name? Are there any other options?Note:https://wiki.jenkins-ci.org/display/JENKINS/Meet+JenkinsJenkins claims that it focuses on Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs. I'm not sure if this is exactly what I am talking about.
Is it reasonable to run processes with CI tools?
continuous integration;cron
We've been using Jenkins as a cron drop in for a couple years now, and here are some pros and cons:ProsIf you are managing a large number of processes across dozens of servers and multiple environments, it makes many things easier.  You get email alerts out of the box, a common dashboard for everything, a web interface for logs, and an easy way to setup additional nodes to run jobs on.  Support teams especially appreciate having this central location for checking problems and re-running jobs. Jenkins plug-in ecosystem is very active and provides a host of additional functionality... I think this is really Jenkins 'killer' feature, since if Jenkins itself doesn't provide what you're looking for (often the case), more often than not there is a plugin that does.  Some of my favorites:  Cron Column, Rebuild, NodeLabel Parameter, Log Parser, and Email-ext.Advanced scheduling/trigger support:  The schedule syntax basically is cron, so you have the same flexbility there, but this is supplemented by Triggers, the REST API, and the Groovy/Java APIConsCentral point of failure:  Because all your jobs are kicked off by one server, if that box goes down and nobody notices, Big Trouble.  So you better have good monitoring to catch outages immediately, as well as all your configurations saved in source control.  Even if you can't get the original server back up, as long as you have your job configs it's trivial to get them setup somewhere else.  If time to resolution is a concern, having a standby pre-configured somewhere is probably a good idea as well.If you have multiple environments (Dev, UAT, Prod), typically you have slightly different versions of a job running on each environment.  Having all these jobs on one Jenkins can become unwieldly, and manually configuring them gets to be a huge pain.  In our case, we run a separate Jenkins 'Cron' instance for each environment.  The instances are installed and configured automatically using an in-house deployment tool.  You may not have something like that, but there are open source tools which do similar things (generate configs using templates).  If you can solve the config generation problem, this makes setting up and deploying Jenkins much easier, and also makes it easier to keep all your stuff in source control. Upgrading Jenkins sometimes breaks functionality, especially with plugins.  Don't upgrade your mission critical Jenkins instance until you've tried the new version somewhere else first.  This is where having a mirror Dev environment with its own Jenkins instance comes in really handy.One thing to perhaps emphasize:  We do indeed also use Jenkins for CI, but this is a separate instance... the 'cron' instances are dedicated to job management, and the 'CI' instance is dedicated to CI.  Separating the concerns seems to make things cleaner.As a side note, I use Jenkins instead of cron on my Linux box at home :)By the way, this is actually a pretty common Jenkins use case.  For example, Sandia National Lab uses Jenkins this way:https://software.sandia.gov/trac/fast/wiki/HudsonAnd there are numerous blog posts and tutorials describing this.  Here are a couple examples:http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/http://morgajel.net/2011/12/12/1108I should also add that this really just pertains to Jenkins, and not all CI tools in general.  Just because Jenkins is well-suited to do this does not mean others (TeamCity, buildbot, etc) are...