Upgrade discussion

Like to open a discussion about the current 2.0… upgrade process.

As I understand it today, the upgrade process goes something like this:

  • Admin area checks a server to see if a new version is present - displays notification if yes
  • Click upgrade link in notification to start process
  • New source/schemas downloaded from server
  • Current source checked against new source. Anything different is saved to var/upgrade directory (including CS changes only).
  • Store is CLOSED
  • new upgrade is installed in current document root
  • Notice given to admin that conflicts exist and to resolve manually
  • After resolving conflicts and applying changes to document root, store can be OPENED



    To me, there is much room for improvement in this process. My main concerns are:
  1. Closing the store and waiting till conflicts are resolved is problematic for merchants. What happens if they don’t have the immediate expertise to do the conflict resolution themselves. Their store will remain offline until they get it done. Great opportunity for consultants, but not good for merchants.
  2. When changes are saved to var/upgrades, all the files in conflict with the new version are saved in the tree. This should be limited to ONLY those files that were in conflict with the OLD source (I.e. locally modified), not the NEW source. This would make it much easier for someone to apply their local changes into the new source via diff/merge.
  3. There is no separation between the process of resolving conflicts in source with changes to the DB schema. I.e. can’t run old source against new schema so difficult to test conflict changes.



    I’d propose something like the following:
  4. Separation be achieved between DB updates and source modification. I.e. becomes a two-step process. a) resolve conflicts in source, b) update schema and apply new source changes.
  5. The upgrade should be downloaded and conflict information provided as it is today. But the document root should not be modified. The upgrade should be installed into a separate tree so the store can remain open when the upgrade conflict resolution is in process.
  6. Then, when conflicts are resolved (tool needs to be provided to verify), the actual upgrade of the store can go forward.



    To do the actual upgrade:
  7. close the store
  8. copy the new upgrade root to the document root
  9. Apply DB changes
  10. Open store



    This would keep the time the store is closed to an absolute minimum.



    I don’t think these changes would be dramatic from an implementation standpoint. But the upgrade process needs to be sensitive to the variety of skills that merchants possess. Some are techy, some are not. Can’t allow someone who pushes a button to get their store closed for possibly days while they dig themselves out. Not everyone will use addons in the customer area to do all their customization (and it’s not possible with current product).



    Be interested in others experience and thoughts.

Great! GO GO CS-CART 2.0!

[quote name=‘tbirnseth’]Can’t allow someone who pushes a button to get their store closed for possibly days while they dig themselves out. Not everyone will use addons in the customer area to do all their customization (and it’s not possible with current product).



Be interested in others experience and thoughts.[/QUOTE]



I’m agree with you.



A “Push Button Upgrade” is perhaps too good to be true…



For example, I cannot use CS-Cart Store Manager on my webhosting account. I don’t understand why (maybe some security rules are transgressed with Store Manager) but never mind, I prefer do it by hand.



With a little luck, “Push Button Upgrade” will be just as impossible!







Lee Li Pop