So far you have learned the content production capabilities of Alfresco using web projects, User Sandboxes, web forms, and workflow. This chapter introduces you to the content delivery and deployment features, of Alfresco. You will understand the concepts behind delivering static content as well as dynamic content to the external production servers. This chapter covers deployment to both live servers as well as to the test servers. This chapter also focuses on the auto deployment feature where the content can be scheduled to be delivered to the production servers automatically.
By the end of this chapter you will have learned how to:
- Install and configure File System Receiver (FSR)
- Use Alfresco Server Receiver (ASR)
- Set up the process for auto deployment
- Deploy to a test server
- Deploy directly from a workflow
- Set up hybrid deployment for both static and dynamic content
Alfresco provides a framework for pushing content from a stage (or authoring) server to live and test servers, as shown in the following figure:
The Alfresco content production environment produces an approved view of a web project called a snapshot. Consider each snapshot as a web project version. Alfresco deployment takes a snapshot and pushes it out to either live or test servers. Consider a sample scenario as shown in the following diagram, where the content from the stage server is deployed to live servers. When snapshot version 2 is deployed to live servers, then the Alfresco deployment engine only copies the files which are either new or modified and removes the files which are deleted when compared to snapshot version 1. The deployment engine is smart, which affects only few files rather than copying all of the files of a web project. Now that the snapshot version 2 is live (deployed to live servers), the editorial staff may work on a future version 3.
Let's say for some reason there is an issue with snapshot version 2, which is live. You have the option of rolling it back to the previous good version of snapshot version 1. You can roll forward or you can roll back to a specific version of a web project snapshot version. This feature is very powerful even from a legal audit point of view, wherein you have an ability to reproduce the website as of a specific date.
Further, the deployment process may be automated so that it happens automatically when content is approved for publishing.
The deployment framework provides a flexible and highly-configurable system to allow you to tailor the system to your requirements. If the Alfresco-supplied components are not suitable, you can plug in your own authenticators, transport implementations, content transformers, and deployment targets.
Alfresco WCM enables previewing the content within the stage server environment. After content creation, the Editorial staff may preview web pages to verify the content, as well as the look and feel. Similarly the content reviewers and business owners may preview to review the web pages during the workflow process.
Because of this powerful feature, you may not need a separate test server to preview and approve the content. The stage server itself is used for both authoring and testing the content. Hence, the content is authored and approved on the stage server, and then deployed to the live servers directly.
However, there can be a situation where you may need a separate test server. For example, if you are deploying content to another frontend application outside of Alfresco such as a PHP or .NET application, or situations when the virtualization server is not capable of providing the preview. Starting with the version 2.2 release, Alfresco introduced the concept of a Test Server.
You deploy the content from a Staging Sandbox to the live server and you deploy the content from User Sandbox or from a workflow to the test server.
Within the live or test server environment, you can push out content to a flat filesystem to be served up by Apache or IIS, or you can push your content into another runtime instance of Alfresco.
Pushing content to a flat filesystem environment is also known as Static Deployment and it is achieved using Alfresco File System Receiver (FSR). Pushing content to another runtime instance of Alfresco is also known as Dynamic Deployment and it is achieved using Alfresco Server Receiver (ASR).
In static deployment, the web pages are already rendered (or baked) before deploying. In dynamic deployment, since the content is in the runtime instance of Alfresco, the web pages will be generated (or fried) at runtime. The following is a summary of static and dynamic delivery models:
|
Static "Bake" Model |
Dynamic "Fry" Model | |
|
Delivery Technology |
Web Servers |
Application Servers |
|
Page Compositing |
Submission time |
Request time |
|
Content deployed to |
Filesystem |
Alfresco Runtime |
|
Content Search |
Not supported |
Supported out of the box |
|
Content Security |
Not supported |
Supported out of the box |
|
Personalization |
Limited |
Unlimited |
|
Performance |
Ultimate |
Less than the "bake" model |
You can consider a hybrid deployment (both static and dynamic) for some business applications. You can define certain static content of the web project such as images, videos, and scripts to be deployed to the filesystem and certain dynamic content such as web pages to be deployed to the Alfresco runtime. This approach gives you good performance as well as personalized and dynamically changing content in a production environment.