While Alfresco WCM contains a sophisticated deployment engine, the options for initiating deployment are rather more limited, comprising the manual 'Deploy Snapshot' function in the Explorer UI, and the automatic 'Auto Deploy' function that can be configured in the Web Project Settings and then requested by an author at submission time.
While these options are useful, they each have their downsides. Manual deployment is, well, highly manual, and in practice it's usually unacceptable to dedicate a Content Manager to monitoring promotions and deploying them as they roll in. Auto-deployment removes the manual step (once authors are trained to check the 'auto-deploy' checkbox during submission to workflow), but has the problem that a high rate of concurrent promotion can overwhelm the deployment system (since each and every promotion is auto-deployed individually, despite the deployment engine offering a far more efficient 'batch' deployment mode).
A Better Alternative
A better approach is to have deployment initiated automatically on a scheduled basis, picking up the latest snapshot at that point in time (which will automatically include all prior snapshots since the last successful deployment).
So what would be involved in developing this as a customisation?
Not very much, as it turns out. Alfresco already includes all of the necessary components to provide this functionality:
All that's needed is some glue code to tie these two components together, and thanks to the generosity of a recent Alfresco Enterprise customer, that glue code has now been developed and is available as part of the alfresco-wcm-deployment project on Google Code.
Under the Hood
As it turns out there was one critical detail that made this slightly less straight forward than I'd expected. Specifically, the action responsible for deploying a Web Site (the AVMDeployWebsite action) isn't responsible for writing deployment reports into the Web Project - that step is performed in the Explorer UI's JSF code instead (in a private class called org.alfresco.web.bean.wcm.DeployWebsiteDialog).
Given that deployment reports are a critical piece of operational reporting information, it was clear that generating the deployment reports in exactly the same fashion as the OOTB 'Deploy Snapshot' and 'Auto Deploy' functions was a high priority. As a result the code doesn't call the AVMDeployWebsite action directly - instead I copied the relevant block of code out of DeployWebsiteDialog and added it to my own custom class†.
Other than that, the code is pretty straight forward. Following Alfresco's ubiquitous 'in-process SOA' pattern I introduced a new service interface (called WebProjectDeploymentService), wired it into my Quartz job class using Spring, then configured it (with the cron expression that controls how frequently it runs) in a separate 'trigger' bean.
As always, if you have any questions or comments, please feel free to reply here. I would request that any bug reports or enhancement requests get raised in the issue tracker in the Google Code project however - they are far easier to monitor there than in the comments on this post.
† Note that this creates upgrade risk, since that code could change in future versions of Alfresco. Given I work with the Alfresco code day-to-day I'm in a better position to detect when such changes have occurred, but if you're doing something like this yourself I would encourage extra diligence in monitoring changes to the original code to ensure your extension doesn't break unexpectedly following an upgrade.
