Deployments, overwriting and pain

[marcus]

My current environment setup is as follows

• Development env for figuring out JSP layouts etc


• Authoring env for content authors to upload and manage site content


• Staging env for business users to get a final preview before content is approved for live


• Live env in standalone app server, that uses webscripts pointing back at a runtime alfresco

The ideal scenario is that the Dev env points via an ASR to the authoring env, via another ASR to the staging env, via an ASR or FSR to the live env. However, because content is actually authored during the second step, and the alfresco deployment mechanism wipes out anything in a target environment not in the source, all content authoring done in the Authoring env is destroyed. Obviously this isn't a workable solution.

Is there some configuration that can be done to the receiver so that it DOESN'T do deletions? I can see how I could use a layered folder to get around the web project being affected by keeping code and content in separate projects, but this is not really workable either as creating a new site using the 'content' site as a template doesn't bring any shared folders across. Am I reduced to going back to rsync?

[pmonks]

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

Some alternatives:

1. 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.


2. (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.


3. 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

[marcus]

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?