You have code on a production server that does not allow Drush to be running and you do not enjoy the idea of copying over live files. If these sites are already tracking a git repository that is great, simply do a push and pull and you are done. It gets more complicated though if the repositories are woefully out of sync or if they have never had a git repository configured.
The solution I devised allows you to update the site locally, make a nice commit, and then fetch it on the remote server and reset the filesystem to the fetch that was just made. Here are the steps:
- Create a git repository within your development site (skip this step if you already have git enabled).
- Use Drush on your development site to update Drupal core.
$drush pm-update drupal
- Test your site and then add and commit the files you have just updated.
$git add -u $git commit -m"Upgrade to Drupal version x.yz"
- Create a remote repository if you do not have one already configured. Once that is created link your development repository to the remote and push your updates.
$git remote add origin RemoteRepositoryURL $git push origin master
- Now, go over to your production site and create a git repository like in step 1 above. Next, you will add the remote, fetch the update from that remote, and then reset your file tree to what you just pulled with the following commands.
$git init $git remote add origin RemoteRepositoryURL $git fetch --all $git reset --hard origin/master
- That last command will rebuild the file system based on repository and from now on you can do normal push and pulls. Make sure to run update.php to get your database in sync with the new Drupal release.
I know the above is quite unorthodox. You also need to be careful as it will only rebuild the files you are tracking. I do not normally advocate for tracking entire Drupal installs but if you are in a situation as detailed above, it may be one of the few ways to have a sane update mechanism. For working with remotes I find the git-scm reference pages very handy.