Moodle Upgrading options - what do you think?

Moodle Upgrading options - what do you think?

by Kahraman Bulut -
Number of replies: 9
Picture of Testers

Dear Moodlers,

I would like to know your opinion, experience and advice on the following Moodle upgrade options. I have listed ADVantages(+) and DISadvantages(-) of each option. Please feel free to share your feedback, which I will use to upgrade from version 3.1.1 (Build: 20160711) to version 3.3.
 

1. Backup (code,moodledata,DB) and upgrade in your production server

+ ADV: use of a single server, no need to for additional servers

- DIS: Production site will not be available during the upgrade

- DIS: If upgrade fails, it may take some time to go back to the backup version

2. Upgrade in a testing server(code) and copy your DB and moodledata 

+ ADV: you production site won't be affected

+ ADV: you only switch when you are satisfied and test all functionality in the new version

-DIS: You need 2 servers/resources: a current and a testing environment

3. Install a new version of Moodle from scratch in a new server. Then recreate identical courses, and then move (backup+restore,export/import) all course, user, grades,enrollment, assessments,.. and copy moodledata.
+ ADV: you production site won't be affected
- DIS: Backup and restore may not be possible for huge courses with many videos and audios
- DIS: How to link moodledata, grades, enrollments activities and resources to courses;
- DIS: User,group export/import may not link users to courses

4. Another better option


Which one do/did you use? Why? Your experience, suggestions, tips and tricks? 

What do you think?
Thanks for your feedback!

Cheers,

Kahraman

Average of ratings: -
In reply to Kahraman Bulut

Re: Moodle Upgrading options - what do you think?

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

You are missing the fact that the production server will be offline the some time in any option.  You cannot have changes being made on your production site while you are transferring the data across so you have to take it offline.

I upgrade my live server.  I have the advantage of being on virtual servers and I can snapshot prior to upgrade.  I download the code, make all the necessary changes and if lucky, the live site is only offline a few minutes for the actual upgrade.  With the other options, I can get everything ready but just prior to the upgrade, I have to rsync the moodledata folder and dump and restore the database again.  So, it actually takes a lot longer that just upgrading live.

 

Average of ratings: -
In reply to Emma Richardson

Re: Moodle Upgrading options - what do you think?

by Kahraman Bulut -
Picture of Testers

Thanks Emma for your input.
Yes, you are right I missed the fact that production is going to be offline for sometime. I updated the related disdvantage.

> "make all the necessary changes"

Can you mention what are these changes are?

Thanks

Average of ratings: -
In reply to Kahraman Bulut

Re: Moodle Upgrading options - what do you think?

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

Option 2: Any change made on the live site while you are working on the development site will need to be synced across before you switch to the dev site.  This means that when you are ready to switch, you need to resync the moodledata folder and the database.  This takes more time that running an upgrade.

Option 3:  Any changes made while you are uploading the courses to the new site will not be reflected in the new site so you need to take the live site offline during this process which is far slower than running an upgrade.

Best solution:

Have a development site that is a clone of your live site.  Test the upgrade.  Fix any issues that may arise on the live site prior to the live site upgrade.  Download the new code, copy across all your plugins/config.php file etc, check permissions etc.  Live site is online during this process.  Take live site offline, run upgrade, put back online.  Live site (if there are no issues) offline less than 15 minutes.

Option 4:  Use git to upgrade.

Average of ratings: Useful (1)
In reply to Emma Richardson

Re: Moodle Upgrading options - what do you think?

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers

Yep, I use Emma's "Best solution" approach.  She is correct that my production server is only down, in my case, less than 10 minutes.  I find this to be a perfect solution.

Average of ratings: -
In reply to Kahraman Bulut

Re: Moodle Upgrading options - what do you think?

by Ken Task -
Picture of Particularly helpful Moodlers

Under your number 4.

Clone production site to  dev site.   Get both sites git.

Use the dev site to do git update and upgrade.

All goes well, then do same on production.

https://docs.moodle.org/33/en/Git_for_Administrators

Aside from getting a backup of code and a DB dump prior to any update or upgrade updates normally take no longer than 5 minutes.   Upgrades longer .... 10 at the most.

moodledata is not touched often ... so it's only new code and the DB for the site that's being updated/upgraded.

Advanced planning/research .... DB server requiremnts for 3.3 and beyond.

'spirit of sharing', Ken



Average of ratings: Useful (1)
In reply to Ken Task

Re: Moodle Upgrading options - what do you think?

by Kahraman Bulut -
Picture of Testers

Thank you all for your feedback!

> "moodledata is not touched often"


Ken, do you need to get moodledata in Git/github as well?

OR you may simply copy it from production to dev-site?

Cheers!

Average of ratings: -
In reply to Kahraman Bulut

Re: Moodle Upgrading options - what do you think?

by Ken Task -
Picture of Particularly helpful Moodlers

moodledata is unique to each implementation of Moodle ... be it production or dev.

Git should deal only with code. (while you could setup a github and your moodledata could be included in a git clone I wouldn't - dynamic nature of cache/localcache/muc etc.   Think it would have potential to confuse your efforts to clone again and test upgrades.

While Emma is right ... one could copy moodledata to the dev implementation, think I'd setup an rsync script (production moodledata to dev moodledata) and have the rsync update (which means add new files but remove old files no longer on production in filedir on the dev moodledata).

Why?   Once having tested an upgrade on dev, then replicating actions/commands, etc. on production, dev sites have a tendency to languish.   Production server is used therefore database has grown, files uploaded to moodle have changed, students come and gone, couses added and removed.   So before doing the next major upgrade, I'd replicate the production server to dev site again.

Git will handle the update to code.   There is an experimental utility now in (3.2 and 3.3) for 'Database Migration'.   Have tried it and it did work.   That would have to create a new database ... let's call it moodledev2017 ... if you name it with a year then just by looking at the DB name one can tell when dev was last migrated and how current dev was when first created.    This then allows you to skip the conversion of the FQDN ... production.yoursite.net to dev.yoursite.net - thus being able to get a dev site setup much more quickly to test the upgrade.

Have a 'customer' that contacts me about once every 2 years - they are upgrading. They have a Quality Assurance mind set.   They spend much of their QA $'s just getting the QA servers up to par ... before they can begin on testing an upgrade because they insist on keeping the QA as it was rather than cloning what they have as production again before upgrading.   Database requirements now much larger than when dev was first setup.   And because they setup servers with different partitioning, work-arounds exist on production that don't exist on production .... like a partition for /var/mysql/ where the databases live.

Bottom line ... make the dev a clone ... no work-arounds need come into play on upgrading production.   The idea is to make your admin life easier ... as close to 'no-brainer' as possible.

My 2 'sense' of course ... nope, spelled it right! ;)

'spirit of sharing', Ken

Average of ratings: Useful (1)
In reply to Ken Task

Re: Moodle Upgrading options - what do you think?

by Kahraman Bulut -
Picture of Testers
Thank you all for your feedback. It's appreciated!
Average of ratings: -