Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Releasing forms/processes to different environments.

Avatar

Level 2

Hi

We've relatively recently started using LiveCycle and we haven't found any decent way of deploying a single module between servers.  The only way we currently have is to

  1. Create a new Application on the development server with the same name as the one we are deploying to.
  2. Copy and pase every single thing from the development Application to this new one.
  3. Create a .lca archive of the new application
  4. Deploy this new application to the test/live environment

The big problems with this are

  1. This method requires the entire application to be released at once, which won't be good when we have multiple people working on different forms.
  2. It doesn't allow us to pull the files from an external source control application (like Visual Sourcesafe)
  3. We're not actually releasing the same thing to each environment.

Does anyone have any alternative methods for handling releases?

Thanks

Dan

6 Replies

Avatar

Level 8

Is the reason that you need to do the copy/paste work because there is something server specific in the process?  If so, you may want to look into using Configuration Parameters instead of hard coding it into the process.  That way you can move the proocess, using an LCA, and set the server specific parameters on deployment.

http://help.adobe.com/en_US/livecycle/9.0/workbenchHelp/help.htm?content=000119.html

Avatar

Level 2

There's nothing server-specific in the code, but if I create an LCA from an application called DEV1 then as far as I'm aware it can only be deployed to an application called DEV1 - so when I need to deploy to an application called TEST1 on another server I need to create an application on the development server called TEST1 and copy+paste everything across before I can create the .LCA file.

If there's a way around this I'd love to know (though it still wouldn't get around the other problem that we have to deploy an entire application at a time rather than just the files that have changed).

Avatar

Level 10

You can also create a patch to an existing LCA if you just want to update it.

Jasmin

Avatar

Level 8

Interesting.  I'm not sure if I have a simple way around your  immediate problem, but other customer's I've worked with handle it a bit  differently.

Rather than call the application by its  development phase (DEV1, TEST1), they usually call it by a more  descriptive name that pertains to the project (MortgageApp,  VacationRequest, FraudInvestigation, etc.)  That allows you to take  advantage of the version control system that is built into LiveCycle.

For  example; Say I am working on an update to the NewHireRequest  application, which currently has a version running in production.   On  the development server I load the production version (if its not already  there) from an LCA.  Then I right-click on the application and choose  New > Application version.  I give it a major and/or minor version  number and click finish.  Now I have a copy of the original with a new  version number.

I can make any modifications to that  application and export it as a new LCA.  Then when I import that LCA to  the test server, it will have the new version number. Once the testig is  complete, the new LCA can be imported and deployed to production.  Any  new requests will automatically start with the last version number.   Processes that are already under way will continue with the previous  version until they complete.

Avatar

Level 2

Ah yes, I hadn't spotted that.  That'll definitely help solve problem 1 listed above.

Thanks a lot.

Avatar

Level 2

Thanks Hodmi.

I'm not sure how workable it is for us though.  Because of the licencing costs of Livecycle we only have three servers.  One for development, one for testing and one for production.  We actually work with six environments though, which means we have to have multiple ones in each server (two on the development box, three on the test box and one on the production box) so we can't give an application the same name on each server.

If there was a way we could keep the application name consistent with six environments without having to pay for more than three servers that would be great.