Continuous Integration Workflows with Reuse is a Meister Benefit over Jenkins

Continuous Integration Workflows Reduces Redundant Work

We often get questions about the use of reusable workflows. OpenMake Meister supports the use of Reusable Workflows for both Builds and Deploys.   Reusable Workflows allows you to define a set of activities that can be re-used over by other Workflows.  This can be very handy in the deployment process in particular.   Workflows that have reuse allows for granular organization of functionality and a high level of re-usability. A Reusable Workflow is defined in the same way as a Nested Workflow.  The difference is in how they are used.  A Reusable Workflow is a set of Workflow Activities that may be used in the same way by multiple Project Teams.  Instead of re-defining these Workflow Activities for every Workflow, the Workflow can instead call another Workflow to perform those Workflow Activities.  If you make a change in the Reusable Workflow, any Workflow that is using that Reusable Workflow will get the new changes at execution.  When running the Workflow Monitor, you will see how each Workflow is called in the correct order, and you will see each step inside that reusable workflow execute.

Jenkins does not offer the ability to nest Workflows in this way.  With Jenkins you must re-create the workflow for every team who needs it. Jenkins was not designed for large organizations with many teams.  When you have defined a standard practice, you want to make sure everyone follows the practice.  This is the purpose of reusable workflows.  You can still use Jenkins, but allow it to call Meister for managing your build workflows.  This way you are optimizing around Jenkins.

 In order to use Reusable Workflows the Environment Variable OMSUBMIT_MAX_USER_PROC must be set to a value of 3. This must be set in the shell that launches the omsubmit executable.  For Example:    OMSUBMIT_MAX_USER_PROC=3


Ms. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that were common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

Related Posts


WebSphere wsadmin get cell name

WebSphere wsadmin get cell name commands Help on using Websphere Wsadmin This post covers how to retrieve a cell name from WebSphere wsadmin. I’ve been posting about supporting WebSphere with Release Engineer for all our Read more...


Distributed builds and Configuring Remote Agents

Distributed Builds and Remote Agents Using Distributed Builds with Remote Agents for Continuous Integration Distributed builds requires the use of Remote Agents.  A common question I see on our support forums is how to configure Read more...


Polarion SVN Importer

Using the Polarion SVN Importer tool Lessons on Polarion SVN Importer On and off over the last few years or so I have been working with the open-source Polarion SVN Importer tool to help customers migrate to Subversion Read more...