Ask Questions and Find Answers

To be perfectly honest, I haven't come across a really deep community discussion around LARs and the use cases, so I really welcome all comments to this post. That said, I'd like to offer my thoughts on LARs and the uses cases as I see them, because I'm beginning to think I'm not on the same page as the developers of LAR functionality.

Right now, the only way to move a "site" (community, etc.) from one instance of liferay to another is through the use of a LAR. In the case of moving a site, it will always be the preferred behavior to delete and replace. That is, I can't think of a use case where I would want to preserve something when I'm trying to migrate a site. (Our use case here is moving changes from a development environment to a staging, or from staging to production, etc.)

Often, it's not that case that we need, or even want, to move an entire site. For example, if a page were added to a dev environment, we most likely only want to copy this page over to a stage environment; carrying the whole community as a LAR is needless bulky and slower, plus it runs into the issues of what to do with other duplicate pages, etc. In these common use cases, a single page, or multiple-but-individually-selectable set of pages would be preferred over a full community import/export. In the case of individual layouts, it would be necessary to have an export checkbox like "include child layouts."

The last of my major concerns is with the importing of LARs: during an import in production, our site does not respond to requests. It seems there is a blocking mechanism in place as the LAR is imported. So in order to push a community from staging to production, we need to employ a fairly complex process of removing one node from our production cluster, pointing it to a new copy of the production database, import the LAR into this "renegade" node, then one-by-one switch our other nodes to this new cluster. (Because of the issues with not deleting child pages, etc., we actually just export and import the full database, but this will cause problems for us as we begin working with multiple communities.) I'm not sure if there is a different algorithm that could be used, such as blocking only the layout currently being replaced and doing one at a time, or something like that, but blocking the entire production site has some significant financial implications for us.

With these use cases in mind, most of the merging abilities laid out in Ray Auge's post don't seem necessary applicable to me. At least for my organization, we will rarely, if ever, want to be merging communities; we'll either want a full community replacement or a simple replacement/addition of a single layout (maybe with children).

That said, we haven't worked with a lot of the user/security settings yet. I do see the need for import/export options about weather to bring user permissions along or not. Admittedly, I have not thought about this issue in as much detail yet.

Thoughts?

We'll try to write up our use case (deployment/Staging/Workflow) and post it here. I think it would be helpful if we know of other usecases to do the same. That will allow us to figure out where we can tackle the problem with a common solution and where the vertical requirements are. Once we identify enough vertical requirements to recognize patterns we can discuss frameworks to facilitate the pluggability of special case implementations.

In the end we want to strive for simple, functional and correct -- everything else is an optimization.