IT Process Automation

Hi,

Does anyone have an automatic\systematic deployment process for deploying a process created in "CA Process Automation" on a development machine to a UAT\PROD machine?    I know that you can export the process to a XML file in development and import the XML file but I'm looking for a more systematic way to do it.

Ideally I would like to create a maven build for XML scripts and have a deployment tool automatically deploy the XML scripts in PROD to a location where "CA Process Automation" is pointing to but was told that this cannot be done since "CA Process Automation" looks for these files in a database.  

Does anyone have any other deployment suggestions?

Thanks,

Brandon

To best of my knowledge, all our customers either import/export the process between development and Prod environments or take a development env DB dump and restore that as part of Prod environment.

However, in PAM 5.0 (our upcoming release) we have a systematic way of migrating data between Dev to Prod environments. We have created three different personas for the same viz., Solution designer persona, Administrator persona and End user persona.

For more details on PAM 5.0, please refer to the below blog post

https://communities.ca.com/community/ca-process-automation/blog/2015/04/14/announcement-pam-50-alpha-build-is-published

Please refer the below blog post to access a local LoD sanbox environment of PAM 5.0.

PAM 4.3 Sandbox instance deployed on LoD network

Hi Brandon,

We actually use something fairly simlar to the deployment strategy you describe.  It's pretty highly customized to our use case, though, and it was originally designed for PAM 3.1, which predates the use of content packages (which may fit your use case better).  The process looks something like this:

1. During development, all of our automation objects are stored in AccuRev as individual XML files.  When one of the objects is updated, we export from CA it and update the XML in the development stream.

2. During our nightly build process, a custom Perl script iterates over all of the automation objects, strips part of the XML wrapper, and concatenates the files it into a single XML.  (This feature is likely obsoleted by content packages these days, but since it still works, we haven't moved away from the old development strategy yet.)

3. The single XML is now a published artifact which is distributed with the build. (We don't source control the single XML directly unless it's a milepost / release version, since it's re-creatable from the source.)

That single XML can now be imported as a single object, and contains nearly all of the processes that we use. We do this step manually because we generally pick and choose which builds we're going to execute against, but there's no reason that you couldn't use a web service call to import the package automatically every time the process runs.

Hope this helps,

Sam