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


Moving from Ant to Meister – No conversion required

Ant to Meister conversion is not required Don’t believe that an Ant to Meister conversion is needed to move to Meister Build services Our competitors would like you to believe that an Ant to Meister Read more...


Application Release Automation with Ansible Galaxy Roles and Release Engineer

Application Release Automation requires the ability to manage both the application stack and server configurations. IT Engines such as Ansible are designed to manage server configurations and the IT Stack, but do not focus on Read more...


DVCS in the Enterprise: Are we there yet?

DVCS Offers Huge Gains and will be Next Generation Version Control Understanding DVCS for Version Control Distributed version control systems (DVCS) have made huge gains in adoption over the past few years and GitHub in Read more...