ÃÛ¶¹ÊÓƵ

Transcript

Hello and welcome, everyone. My name is Abhishek Dwevedi, and in this video, we are going to learn about mutable and immutable content. After completing this video, you should be able to describe and differentiate between mutable and immutable content. As we have seen in previous videos, AEM application deployment must be comprised of a single AEM package.

This package should in turn contain sub-packages that comprise everything required by the application to function, including code, configuration, or any supporting baseline content. On the other hand, AEM as a cloud service requires a separation of content and code, which means, a single content package cannot deploy to both/apps or runtime writeable areas like content, conf, home, et cetera. Apps and loops are considered immutable areas of failure, as they cannot be changed after AEM is started. Any attempt to change an immutable area at runtime will fail.

Everything else in the repository, like content, conf, var folder, home, EDC, oak indexes, et cetera, are mutable areas, meaning they can be changed at runtime. For immutable content packages, all content and code persisted in immutable repository must be checked into Git and deployed to Cloud Manager. In other words, unlike current AEM solutions, code is never directly deployed to running AEM instance. This ensures that the code running for a given release in any cloud environment is identical, which eliminates the risk of unintentional code variation on production environments. As application changes due to blue-green deployment patterns are enabled by switch, they cannot depend on changes in the mutable repository, with exception of service users, their ACL’s, node types and index definitions changes.

For customers with existing code bases, it is very critical to go through the repository restructuring exercise. So, it ensures the smooth migration or upgradation to AEM as a cloud service repository.

For mutable content, in some cases, it might be useful to prepare content changes in source control, so it can be deployed by Cloud Manager.

For example, it might be reasonable to seek certain root folder structures or lineup changes in editable templates to enable policies in those for components that were updated by an application deployment. It is very important to note that there is no mechanism to roll back the mutable content package changes after they have been applied. If customers detect a problem, they can choose to fix it in their next code release or as a last resort, restore the entire system to a point in time before the deployment. Now you should be able to describe and differentiate between mutable and immutable content. Thank you for watching this video. Have a great day. -