Contents
There are different upgrading paths that can be undertaken. While there is no right or wrong way to approach the upgrade so long as the end goal is achieved, a good professional would strive to provide the less painful and the most efficient ways for their clients.
The AEM upgrade usually includes the following two:
– application logic changes
– configuration changes
– data models changes
Application Logic Changes
Changing the Application Logic operating on the existing set of data is a straightforward. In AEM terms, upgrading the OSGI bundle (Java code) and the Javascript portion does not pose any significant risks, as long as all the code is is using proper run mode configurations.
Configuration Changes
Application configuration usually defines certain constants that can have different values, based on the environment type. For example, development environment, may hold API keys for development purpose only, production environment may hold different keys that are valid only in life application. AEM has a well known approach to use so called “run modes” to identify the type of the environment and based on that the application shall apply the proper configuration values.
Data Models Changes
Data model changes are related to
Introducing a new set of data
Replacing existing data with new ones
Removing data fields.
Any of these might require data migration from the existing application version to the new one. Data migration can be done manually or automated.
Adding few constraints to the upgrade process – such as meeting certain service level agreements can be also defining on the application architecture.
Use Case: Notification Component
Your site needs to notify your users for important news, those news has to be pushed no later than a given amount of time – let say 2 hours.
The notification logic has been using three fields to define text, link (URL), and title for the link in the existing release.
The requirement for the new release added to this component a requirement to provide rich text experience to the notification. Rich text will include capability to define text areas, and links within the text, separate paragraphs can be used, etc. the advantage is obvious.
During the design, you have decided to use Rich Text Editor (RTE) component. Hence new repository field has been introduced to hold the markup, generated by the RTE. So far so good. You have coded the solution and communicated that the new component will not use the old fields and the new notification snippets has to be re-entered manually, which according to your users is feasible, based on the number of the existing notifications.
Well everything seems to be rosy, until you have been told that the only authoring environment will be upgraded and used to serve both the old publish instances (still serving the life site) , as well as the new publish instances, which will be using the upgraded application version.
| ————-> Publish (v1.0) online
Author (v1.1) |
|————–> Publish (v1.1) offline
The above picture represents a state that can take up few days. What is the problem? I am sure you have noticed it.
The upgraded application will have the new RTE component with the empty textfield, replacing the old fields, which were deleted during the application UI overhaul. At this point, authors cannot meet the SLA of 2 hours, if the new notification has to be presented to the users. The backward compatibility is gone!
How to fix this problem?
Option 1: Going back to square one: revert to the old code and deploy. Not really a solution, but a temporary roll back to meet the SLA, until you come up with another solution.
Option 2: Provide a component that keeps the old interface and code logic, plus adds the new interface (for RTE) and considers the new logic. Duplication of data and efforts to enter them! But what about once the upgrade is completed? How to remove the old logic. Wait till the next code deploy, add a toggle logic to hide the old user interface and prevent authors to continue using them?
Option 3: Upgrade the code to the new RTE logic and data field, as you initially coded it, but add a flexible upgrade approach to introduce a second Author instance that will be used to keep the data during that interim upgrade state.
Which option you would be using? Is there any better approach? I would love to hear from you?
1,735 total views, 3 views today