topic Re: Deployments, overwriting and pain in Alfresco Archive

Deployments, overwriting and pain

marcus — Fri, 23 May 2008 02:15:13 GMT

My current environment setup is as followsDevelopment env for figuring out JSP layouts etcAuthoring env for content authors to upload and manage site contentStaging env for business users to get a final preview before content is approved for liveLive env in standalone app server, that uses webscript

Re: Deployments, overwriting and pain

pmonks — Sun, 25 May 2008 14:58:50 GMT

Yeah as described this won't work - Alfresco deployment doesn't support cross-repository merging (which is implied by this model).

Some alternatives:

Deploy your developer assets (JSPs, etc.) to a user sandbox in the authoring instance either manually or via a build / deploy script (similar to how you'd do things if this was a vanilla webapp with no Alfresco anywhere in the picture). You might use FTP or CIFS for this.

(if you're using 2.2) have separate Web Projects for your developer assets and content assets, and "fold" them together (via layering) into a single Web Project (either a third Web Project, or one of the existing ones) that is then used for deployment.

Consider switching to the "content in Alfresco / code outside Alfresco" model, where Alfresco is only responsible for managing and deploying your content and code management and deployment is handled separately (ie. using an SCM tool, build and deploy scripts, etc.). See http://forums.alfresco.com/viewtopic.php?t=11845 for a lengthy discussion of this model.

Cheers,
Peter

Re: Deployments, overwriting and pain

marcus — Fri, 06 Jun 2008 01:11:45 GMT

Having looked into the DeploymentServiceImpl, is there a reason it shouldn't support merging instead of replacement? I've made a couple of modifications to the service (only in alfresco -> alfresco deployment scenarios) to only delete remote assets if they were published from 'this' server, using a property value to flag which server it was published from. Is there a problem doing things this way that are going to come back and bite me? I've also made some modifications to allow you to specify which remote project to deploy to (instead of the default of the same name as 'this' one), so that it can be deployed to a user sandbox on the staging server for workflow to be executed against things once everything is deployed. Is there likely to be any problems by having a user sandbox instead of a staging sandbox as the target for a deployment?