使用CI工具运行流程是否合理？

在我的公司中，我们经历了不同的Cron工作（在多个系统上）的泥潭，并且手动启动了流程，这些流程使我们的业务正常运转，这是多年的权宜之计和后来的疏忽的结果。

有一天，出于明显的原因，我们将需要提出一个更加集中的解决方案。

我们一直在考虑的一个想法是使用我们的持续集成软件（Jenkins）运行这些过程，这似乎是合乎逻辑的。

我的问题是：其他公司也在这样做吗？这是普遍接受的做法吗？这是否与名称中隐含的CI工具的定义不冲突？还有其他选择吗？

注意：https： //wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

詹金斯声称，它专注于“监视外部运行的作业的执行情况，例如cron作业和procmail作业”。我不确定这是否正是我在说的。

几年来，我们一直在使用Jenkins作为Cron的替代品，这里有一些优点和缺点：

优点

• 如果您要在数十个服务器和多个环境中管理大量进程，则使许多事情变得容易。您可以立即获得电子邮件警报，适用于所有情况的通用仪表板，用于日志的Web界面以及设置其他节点以运行作业的简便方法。支持团队尤其喜欢在中心位置检查问题并重新运行作业。

• Jenkins插件生态系统非常活跃，并提供了许多附加功能...我认为这确实是Jenkins的“杀手”功能，因为如果Jenkins本身没有提供您想要的东西（通常是这种情况），那么更多通常没有插件可以。我最喜欢的一些：Cron列，Rebuild，NodeLabel参数，Log Parser和Email-ext。

• 先进的调度/触发支持：调度语法基本上是cron，因此您具有相同的灵活性，但是触发器，REST API和Groovy / Java API对此进行了补充

缺点

• 失败的中心点：因为所有工作都是由一台服务器启动的，所以如果该机箱掉​​下来却没人注意到，那就是“大麻烦”。因此，最好具有良好的监视功能，以立即捕获中断，并将所有配置保存在源代码管理中。即使您无法备份原始服务器，只要您有工作配置，也可以在其他位置进行设置。如果需要时间解决，那么在某处预配置备用数据库也是一个好主意。

• 如果您有多个环境（Dev，UAT，Prod），则通常在每个环境上运行的作业版本都会略有不同。将所有这些工作放在一个Jenkins上可能变得很繁琐，而手动配置它们将是一个巨大的痛苦。在我们的案例中，我们为每个环境运行一个单独的Jenkins'Cron'实例。使用内部部署工具自动安装和配置实例。您可能没有类似的东西，但是有开源工具可以做类似的事情（使用模板生成配置）。如果您可以解决配置生成问题，那么这将使设置和部署Jenkins更加容易，并且还可以使所有内容都保留在源代码控制中。

• 升级Jenkins有时会破坏功能，尤其是使用插件时。在先尝试其他地方的新版本之前，请勿升级关键任务Jenkins实例。在这里，拥有自己的Jenkins实例的镜像Dev环境非常方便。

需要强调的一件事：我们确实也将Jenkins用于CI，但这是一个单独的实例……“ cron”实例专用于作业管理，而“ CI”实例专用于CI。分离关注点似乎可以使事情变得更清洁。

附带说明一下，我在家中的Linux机器上使用Jenkins而不是cron ：)

顺便说一下，这实际上是一个非常常见的Jenkins用例。例如，桑迪亚国家实验室以这种方式使用詹金斯：https： //software.sandia.gov/trac/fast/wiki/Hudson

并且有许多博客文章和教程对此进行了描述。以下是几个示例：http : //blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

http://morgajel.net/2011/12/12/1108

我还应该补充一点，这实际上仅与Jenkins有关，而并非所有CI工具都适用。仅仅因为詹金斯非常适合这样做，并不意味着其他人（TeamCity，buildbot等）都可以...

我会说您在这里没有使用合适的工具，因为CI工具的主要目的是它们监视某些东西（通常是您的源代码），并且当有更改时，它们会启动构建/部署/进行任何操作。

但是，这些工具可以运行计划的作业（例如，TeamCity 可以运行），因此您可以在没有人时部署网站（例如）。因此，将所有运行的任务放在一个中央列表实际上是一个好主意。这些工具还应允许您决定这些作业的运行时间和频率。

另一个好处是，您甚至可以远程监视系统（如您所愿）。

因此，总的来说，我认为这是明智的选择。

听起来cron已经可以满足您的需求。我建议您从更好地记录系统开始。审核各种系统，并汇总在哪些计算机上运行哪些进程的完整列表。

然后考虑指定一台专用计算机来运行所有这些cron进程。确保记录这是哪台计算机，并分配适当的管理员权限来控制它。将所有的cronjobs放在那台机器上，然后就可以对各种自动化过程进行集中控制。

我的直觉反应是一样的，即您使用的工具中具有计划的概念来执行工作计划程序。

您没有提到您的工作是什么，但是您提到的CRON让我猜测它们是shell脚本等。那里有开源和商业性的工作计划程序包。有时它们被称为批处理调度程序。有些人只会包装CRON并使其更加友好。有些工具（例如Quartz调度程序）可以对作业进行强大的管理，但是要求将它们实现为Java类。您可能会使用它，并使用Java包装器将运行时调用包装到各种脚本中。我相信，如果您进一步看，将会找到很多选择。

不要将CI用于运行与构建无关的定期任务。

对于与系统维护无关的任务，也请避免使用cron。

使用正确的工具。对于应用程序需求-尝试使用基于AMQP的解决方案。

附言：我知道，该计划适合您的情况。另一方面，您还有很多任务-因此，请尝试为他们编写主管应用。

您需要将企业服务总线（ESB）用于此类任务。

现在，我的背景是Windows / BizTalk，但我确定所有等效项都存在于Unix方面。我们通常要做的是在BizTalk框上设置流程，该流程负责启动另一个框上的内容，监视进度/错误，并将状态报告回SharePoint（或Web）门户，或者发送电子邮件和这样是否需要引起注意。

这种方法的好处是，各种业务流程的所有配置和管理都位于中央，因此您知道从哪里开始。该软件已经存在，可以让您从物理配置中提取编码部分（在BizTalk中，您可以针对逻辑“端口”（如sql server）进行编程，然后在生产中，如果sql box更改了位置或进行了升级或其他操作，您可以可以再次使用其管理工具更改已配置的物理端口，我确定在Unix端存在相同的功能）。

使用CI工具的好处是，如果您的流程出错，您可以自动重新物理地提交消息，并且可以建立一个群集的故障转移环境，并拥有一个更适合的记录和日志记录系统；同样，一旦有了系统，就可以使您开始设计要使用的组织，或者更好地利用SOA。不利的一面是，取决于组织的规模，开发工作可能会很艰巨，而且许可成本可能会很高。

从理论上讲，您有一个位置可以控制所有不同的工作，这很有意义，但是，基于像“圣杯”这样的行业经验，您将需要在这里进行cron作业，在此处执行bash脚本并在此处进行cli脚本。

还有一个口号是“如果没有破裂，请不要修复”，因此，在进行深入研究的过程中，最初应集中精力记录运行的脚本，运行的脚本和所使用的系统，以便您“知道”您的业务如何运作。

然后，作为一项长期策略，设置一个集中的系统来运行这些作业，明智地选择解决方案，因为您将不得不接受它。然后，对于您在业务体系结构中添加的每个更改请求，增强，升级，错误修复或新解决方案，请确保将其计划的和自动化的任务添加到“企业控制解决方案”中。

这样，您就可以从一批脚本逐渐迁移到对企业更友好的环境。

在与我合作的大型企业系统中，他们倾向于使用设计用于计划的工具。我使用过的最受欢迎的是CA7。它使您可以集中所有系统的所有调度。

Cron通常用于单台计算机，尽管您可以通过ssh远程调用来“破解”它。但是，它不会具有依赖项和其他内容的概念。对于范围更受限制的运营团队，最好使用一种工具。