Build a simpler, faster, scalable and offline upgrade/verifier process

• Type: Story
• Status: Closed
• Priority: Minor
• Resolution: Completed
• Affects Version/s: None
• Fix Version/s: Master
• Component/s: Core Infrastructure, Database Upgrade Framework
• Labels:
  • must-for-freeze
  • uniform_test_not_needed

Our current upgrade and verify process are executed online at the time the portal is started. This has turned out to be really painful for many of our customers (long and faulty processes). The main goals of the current story are:

• Create an offline process which can be executed as an standalone process. You no longer need to start the portal to execute the upgrade/verify process

• Faster processes: we will be looking for a solution where we can speedup the execution time of our current upgrades/verifiers.

• Resilient process: we will try to create a more resilient process where we will try to minimice the errors

• Provide useful information: we are looking for a solution where the user could get some insights about what's going on during the execution of the upgrades/verifiers.

Some high level details

• Apps will have an independent upgrade/verify process module which won't be deployed at runtime.

• Apps will have a requirement on the schema version they need (through a capability definition). Modules won't get resolved until this dependency is properly satisfied. In case the app is being newly installed it won't get resolved: the administrator will need to execute the database scripts

• The upgrade/verify process of the core will be moved offline as well. When doing a fresh Liferay installation we won't execute the verify process, we'll only do it after an upgrade process is executed.

Some open questions

• Installing a new bundle which requires a database action should be unresolved by default, and the SQL scripts should be executed in order to get properly resolved. However, when you are not running in production (development environments, pre-production environments, ...), do you still need this behaviour?

• The above concept applies for upgrade/verify process. Should we have the ability to support upgrade/verification at deploy time? At least for a newly installed application we should have some mechanism to create the initial configuration "on the fly"