Skip to main content
commvault.com commvault.com

Hi Gurus,

I am looking for a solution that would allow us to use our sandbox Commcell to act as a repository for our Custom workflows. The idea is we would develop all workflows in the sandbox and when complete deploy them to the production Commcells.

Is anyone aware of any out of the box software that would do this, or are we better off writing a custom workflow to do the job? I am interested in what other people are using to accomplish this, if at all.

Regards

Not sure if its helpful but you can have multiple workflow engines. When you deploy it, it always asks which engine to deploy on - so you can install a ‘sandboxed’ workflow engine while developing. Adding @RMcG again for any suggestions ;)

Hi,

I think you are talking about a utility to MOVE the workflows from the DEV environment to the PRODUCTION environment.

We have a few internal apps built on workflows that consist of many workflows and when its time to deploy them on production we manually export the workflow xml and copy the it to the production server then deploy it there.

This of course can be automated but we found that doing it manually we wanted to have or eyes on it.

The most important aspect of this is the following:

Make sure that EVERYTHING in the workflow that describes ANYTHING about the environment in which it runs (File paths, database servers, API end points etc..) are all externalized from the workflow itself.  You should use configuration variables for this or build another mechanism that defines this.

When you move workflows from DEV to PRODUCTION now, how are you controlling the environment differences and how did you plan to do that when automated?

As @Damian Andre pointed out you can have a separate “sandbox” workflow engine in the same CommCell for your testing. If your automation is complex or critical to daily operations then I personally prefer having a separate CommCell to take pressure off the upgrade process. Eg feature releases can be applied to the test CommCell and all the automation tested prior to upgrading production. 

As @DaveO mentioned a good practice is to expose all your environment specific variables as workflow configuration properties. The initial values for these properties when a workflow is first deployed to a new CommCell will be the default values set for each in the workflow schema. The values are then stored in the local CommCell so when you re-import a new version of the same workflow from another CommCell (whether manually or via API) then the same local values for the configuration properties remain in place.

Hi,

I think you are talking about a utility to MOVE the workflows from the DEV environment to the PRODUCTION environment.

We have a few internal apps built on workflows that consist of many workflows and when its time to deploy them on production we manually export the workflow xml and copy the it to the production server then deploy it there.

This of course can be automated but we found that doing it manually we wanted to have or eyes on it.

The most important aspect of this is the following:

Make sure that EVERYTHING in the workflow that describes ANYTHING about the environment in which it runs (File paths, database servers, API end points etc..) are all externalized from the workflow itself.  You should use configuration variables for this or build another mechanism that defines this.

When you move workflows from DEV to PRODUCTION now, how are you controlling the environment differences and how did you plan to do that when automated?

Thanks DavO, yes you are correct a utility to move from test to prod, sorry for the confusion on the “sandbox” wording there.
This looks like what we are after here, generally we would control them by manually exporting from DEV and import the other end, we aim to  make the original workflows compatible in all commcells wihout edits.
Some work to do there as well in a few of them, but we will update the coed there as required.

Many thanks

Terms & ConditionsCookie settings