Best Practice for Developing with LiveCycle Workbench ES2 – Better Parallel Development: Operations

Author: JianJun Jiao
Editor: Suhas Kakkadasam Sridhara Yogin

LiveCycle Workbench ES2 can process conflicts in parallel development, but for better parallel development, we’d better know which operations will affect operations other developers perform.

In Workbench ES2, there are six operations on application assets and seven operations on applications which could affect each other when they are carried out in parallel.

Note: Operations in bold are specific for assets or applications.
Operations related to application assets are:

  • Check in
  • Check out
  • Delete
  • Synchronize
  • Revert
  • Invoke

Operations related to applications are:

  • Deploy
  • Undeploy
  • Check in
  • Check out
  • Delete
  • Synchronize
  • Revert

From an implementation perspective of these operations in LiveCycle ES2, they can be categorized into three groups by how much developers would affect each other when they carry out these operations.

  • High: check out and delete
  • Medium: check in, deploy, undeploy and invoke
  • Low: revert and synchronize

Broadly, the types of operations that a developer carries on in Workbench ES2 can be categorized into three groups by the frequency of how often the developer performs them.

  • Executed frequently: Check in, check out and synchronize. During development, these operations would be performed highly frequently.
  • Executed occasionally: invoke, deploy, undeploy and synchronize.
  • Executed rarely: delete and revert.

Among these operations, check-out is executed frequently and affects others highly. Workbench provides a “lock” to each application asset. Although the “lock” is not obvious to users, it makes Workbench support parallel development accordingly. When a developer checks out an asset, the developer gets the “lock”. After that, if another developer tries to check out the same asset, a warning dialog is shown “File is currently checked out by …”.

 

 

 

 

 

 

 

 

If the second developer selects to force check out the file, the second developer gets the “lock” but the first developer loses the “lock” because the “lock” is exclusive. After that, when the first developer tries to check in the file, a warning dialog will be prompted the operation failed and then the status of the asset is reset to check-in from check-out. If the first developer has made some changes to the assets, although check-in fails, the changes remain in the local copy of the file. Once you synchronize the file, the changes in local copy will be missing. So if you want to save the local copy, do it before you synchronize it.

 

 

 

 

 

 

Since the “force check-out” nullifies others’ “lock” on assets, it should seldom be used or used very carefully in an application if there are other developers working on the same application.

Generally, the operation deploy/undeploy is seldom carried out in design time but more often in debug time. The conflict happens when one deploys the application and the other undeploys it. The consequence is that only one operation can take effect. So, a secure way to check the deployment status is to synchronize the application.

The deletion of files is not used too often. Executing operations on an application asset which has been deleted from server by others is not a problem because it can detect that the asset does not exist on the server.

 

 

 

 

The “revert” and “synchronize” only affects the local copy of assets so such operations won’t affect others.

The operation “synchronize” is suggested to use often in parallel development. Thus, you can make sure the applications and application assets are in a synchronized state.

Once we understand how Workbench settles conflicts, we could use Workbench for better parallel development.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)
This entry was posted in Adobe LiveCycle ES2 (9.0.x) and tagged , , , , , , . Bookmark the permalink.

6 Responses to Best Practice for Developing with LiveCycle Workbench ES2 – Better Parallel Development: Operations

  1. Pat91260 says:

    Télécharger le produit merci

    • Mark Jiao says:

      Pas de quoi. :)
      Thanks for your comment. I actually doesn’t know French. If you have further questions, please try to use English. Thanks.

  2. Amko says:

    “parallel development” by definition needs to involve ability for two or more developers to work in isolation on the same asset and be able to merge their changes (with our without merge conflicts resolutions, etc). As we know Workbench doesn’t (yet?) have support for that.

    • Mark Jiao says:

      You’re right: Workbench doesn’t have the function to merge changes on assets. But, this is really a good idea. I’d like to submit it as a new feature request. Thanks Amko.

  3. Thank you for another essential article. Where else could anyone get that kind of information in such a complete way of writing?Best regards from Ireland.

  4. Ambika says:

    Hi,

    This is a great article. It has helped us to setup some beat practices around our development process. However, we are still facing some issues during parallel development. Just wanted to know, if there is a way to either

    1) synchronize the applications programatically?
    2) or create a team workspace from where developers can create LCAs?

    Thanks in advance
    Ambika