E-mail
As part of ensuring a strong user-base, it's important that stable release to subsequent stable release upgrades proceed smoothly and for the most common CiviCRM instances can be reduced to a one-click upgrade "a la WordPress". Currently, upgrades can fail for a number of reasons during the upgrade process. It would be helpful for all users if the upgrade process was more transparent (i.e. verbose step by step output) and also in case of upgrade failure, the database did not get stuck in a zombie state where future upgrades are not possible. As with any automated upgrade process, it should automatically incorporate a roll-back mechanism instead of expecting the user to do it with foresight.
- Make all logging in civicrm_log for the upgrade visible to the user performing the upgrade
- Make each DB schema upgrade step only from stable to the next stable release altogether avoiding all alpha and beta incremental schemas
- Engineer a way of rolling-up upgrades that will allow users to go from stable to next stable release with a single incremental schema and code update (i.e. avoid all alpha, beta steps altogether)
- Avoid zombie "failed update database" states by incorporating a roll-back mechanism that is automatically triggered at upgrade time (for Drupal sites, drush can be used to put the site in maintenance mode and create a dump)
Labels:
3 Comments
Hide/Show CommentsMay 10, 2011
JoeMurray
It would be fairly easy to modify GenCode to spit out upgrade mysql for stable to stable releases.
May 25, 2011
Evan Donovan
Here's a few more suggestions:
1) In the web-based upgrade, have the database schema updates run with a JS progressbar showing, and use AJAX to indicate the incremental progress of the update (as Drupal does, for example). As is, the update of a large CiviCRM install takes a tremendously long time with no feedback to the user, so it is unclear whether it is still working, or has stalled.
2) Have a command line update process? Moodle does this, and it works a bit more cleanly than a web-based process, which is more prone to accidentally getting terminated before completion.
3) Make migration of a CiviCRM site smoother, in terms of switching file paths & URLs so that you don't have to do the updateConfigBackend process on it using the old CiviCRM code prior to running the new CiviCRM code on the test site for the initial testing of the upgrade. I understand that this is improved in 3.4.2, though?
May 25, 2011
Evan Donovan
Found the following in docs for a drush based upgrade: [CRMDOC40:Drupal CiviCRM upgrade script based on drush]
I haven't tested that though so I don't know how well it works yet. Looks like it is a work in progress.