feat: Forward Deployment

[rmehta]

Bonus:

1. Make the migrate command in framework interactive
2. Make the UI also interactive

[tanmoysrt]

During migration,

• We will take backup for safeguard (user can opt-out)
• If the migration stuck in between, we will just pause it and ask user to fix it
  • We need to provide some UI for different scenarios. For example, - If migration breaks at some DDL for changing field from string to int and the row has some string value which can't be casted to int, we should show a interactive ui to fix it
  • We need to do a analysis of failures on FC and sort out the issues on priority
• Users will always have the option to rollback (but it will not be automated)

Apart from the above information, We need to make migration less error prone. Few ideas that we have discussed

• Try to block app before installation and migration, if it has any invalid imports, invalid hooks
• Check if python and node dependencies are fine, try to analysis to avoid any dependency resolution conflict.
• For each framework version, fix the node LTS version. Every different app on that version can't use different node version.
• Check if the defined hooks are valid.
• Don't pull changes in apps folder directly. Put it at some different folder first to do the analysis
• On failed installation or migration, ensure we aren't leaving any inconsistent state on the site.

This one needs changes both on pilot and framework end. In v0.1 at-least, we need to have this behaviour and then we can keep adding more cases.

We can also explore mariadb flashback or mariadb binlog replay to rescue the system where it's not possible take backup.

[rmehta]

Apart from the above information, We need to make migration less error prone. Few ideas that we have discussed

The goal: Keep framework operational even when a faulty app is installed.