Activiti作为持续集成协调器的评估

时间:2014-01-31 18:56:11

标签: bpm activiti

我在DevOps领域工作,目前支持过于复杂的CI系统。它的目的是测试&验证多个Java工件,以防止每个工件和工件相互之间的测试。我们有多个Jenkins实例和复杂的自定义工作流,但它们共享相同的限制:缺乏资源控制。我们最终得到了一堆纯技术的Jenkins工作来处理这些限制,但它们并不完美,初始工作流程变得过于膨胀。

在这里,我向您询问有关Activiti BPM引擎在CI流程中的适用性的专业知识。

我们对当前流程存在以下问题:

  • 云节点可以从一个Jenkins作业移交给另一个。如果工作流程在中间终止(假设功能测试在新构建的工件上失败),那么我们必须释放这些节点。
  • 作业可以自己消耗多种资源 - 数据库,多个节点的环境等。当工作流程完成时,必须释放这些资源

理想情况下,我们应该能够在某些DSL中定义工作流程步骤并将资源绑定到这些步骤。稍后,在工作流程执行期间,工作流引擎可以确定何时首先需要资源,并在该步骤之前(根据资源类型)从适当的池/提供者请求它们。

每个步骤完成后,工作流引擎将我称之为“垃圾收集”的资源。它可以计算(基于提供的DSL)仍然可以从当前状态到达的步骤列表以及绑定到这些步骤的资源列表。之后,可以构建一个列表(当前分配的资源减去未来所需的资源)。该列表将进入垃圾收集。

通过这样的“垃圾收集”,我试图避免过度复杂的手动资源生命周期控制逻辑,这些逻辑将嵌入到工作流定义中并且会使其膨胀。我希望有清晰且易于理解(并且易于支持)的工作流程。

您认为使用Activiti或任何其他BPM引擎可以轻松完成吗?

1 个答案:

答案 0 :(得分:1)

Andrev,

这可以通过有限的努力来实现。我们使用开源BPMS Eclipse Stardust http://www.eclipse.org/stardust/

为QA环境创建了类似的工作流程

祝你好运

罗布