Author: JianJun Jiao
Editor: Suhas Kakkadasam Sridhara Yogin
Customers using LiveCycle Workbench to develop solutions will have the following requirements:
Note: To differentiate a customer’s LiveCycle application with an application in Workbench, we take “project” as customers’ LiveCycle application.
1. Three environments (DEV – for development of LiveCycle applications, TEST – for testing the developed LiveCycle Applications, PRODUCTION – for deploying and using LiveCycle applications.);
– Project could be transferred to cross environments smoothly.
2. Multiple active development streams aka. parallel development with different developer roles;
– Roles could be process developer, form developer, Flex developer, schema developer and so on;
3. An iterative development style;
– Project could be handed over for testing or production while development of later versions can continue.
LiveCycle Workbench ES2 provides necessary fundamental functionality so that these development requirements can be met. The new development model in LiveCycle ES2 is application centric rather than repository centric that was used in previous versions.
Here is a general solution:
1. Use multiple structured applications for parallel development and resource management;
2. Make use of application versions for iterations;
3. Use LiveCycle archives for transitions;
Here is an application structure sample:
In LiveCycle ES, all processes, forms and other assets are stored in a flat structure called repository. But in LiveCycle ES2, application is used to manage resources which are called application assets. A LiveCycle application is simply and logically a container of assets during design-time.
In LiveCycle Workbench ES2, it’s suggested several applications be used to better manage the project resources. It’s to say one project could have several LiveCycle applications in Workbench.
For the sample application structure above, it has some advantages:
- Categorize different type of assets in different applications. Forms and processes could be put in different applications. Thus, the project is more logical and administrable. Subsequently, multiple developers of different roles can work more effectively on the project in parallel.
- Some resources say fragments and schemas are categorized together so they can be better reused.
- Reduce the impact scope when developers do some operations say deployment/undeployment applications.
- Better support the parallel development. Generally, the more applications the team used, the less team members would affect each other.
- It leads to better performance. It takes much more time to do operations say synchronize/deploy on one application with a big account of assets. That’s to say, the performance thus degradates a lot on a large application. For LiveCycle ES2, it’s recommended the count of assets in one application should be less than 50.
In LiveCycle Workbench ES2, every application version is composed by a major version and a minor version. For every application asset, it has revisions. LiveCycle developers can make use of these versions for iterations or even releases. Generally, a release could be a combination of different versions of applications.
Talking to transitions between development, testing and production environment, LiveCycle archives can be used. In Workbench, you can create an archive for each application; or, you can create an archive for all applications of your project. These archives then can be imported to other environments.
Original article at http://blogs.adobe.com/livecycle/2011/06/best-practice-for-developing-with-livecycle-workbench-es2-%E2%80%93-application-structure-iteration-and-transition.html.