Good ideas.
I wonder, however, at what step does Moodle bring any custom code that folks have added to there working moodle into the new moodle, test it so that it runs correctly, and if it doesn't, the upgrade process is aborted?
Quite honestly, some folks who really know their moodle and are good with UNIX actually do write scripts to do all of this. I am not that good with UNIX scripting. GIT is fairly automated, but I am not a GIT kind of person because I am too afraid that it is a little to transparent. Maybe I will GIT someday. So instead, I have my own 7-step process that takes about 10 minutes for an upgrade. I am very careful doing the five steps. On any major release, I test the new moodle on an experimental server. I have my Moodle in "maintenance mode" for around 3 minutes. Often, I don't mention anything to students and don't even put my moodle into maintenance mode. Of course, I don't do these upgrades when users are on my moodle. Some times, like Saturday mornings, are not too busy. I just wait until it looks like I have a window. I could put these 5 steps together, but I like to keep doing them just to remind myself what needs to be done.
Here are the seven steps:
1) Download new moodle into temporary folder. (maybe 2 minutes or so)
2) Unpack it. (10 secs)
3) Move config.php into the new temporary moodle folder. (about 10 secs)
4) Install addins (checklist and collapsed topics) into the new Moodle. (about 5 minutes)
(now is when I put my moodle into maintenance mode)
5) Rename the current moodle to moodlex (less than 5 secs)
6) Move the new moodle from its temporary location to the real ../moodle location. (less than 5 secs)
7) Start moodle (it does its own upgrade) (about a minute)
(now is when I turn maintenance mode off)
If Moodle is into a new "dot" release, I do these 7 steps on my experimental moodle first, then repeat them on my production moodle.