updating drupal with drush and avoiding empty /htdocs

[jamie]

hi,

when you update drupal using drush, while/before it downloads the new version, it empties the folder it is in and stores that in a backup folder, then untars the latest version into the empty folder.

what happens if you are using it in the root folder of your site, is that although you have put your site into maintenance mode, the actual /htdocs folder is empty for a few seconds, meaning your entire site and any other apps contained within the /htdocs folder are offline.

normally i can wait until offpeak times to do drupal updates, but of late there have been several critical security updates which require immediate action. what do other people do to avoid taking the site completely down whilst updating drupal? (even if only for a few seconds)

i have considered having a staging vhost which just contains the drupal folder and files on a bare bones installation. if that works, then have a small script which deletes only the drupal folders/files on the production vhost and mv's the updated ones over. i could use an atomic operation such as mv which is almost instantaneous?

cheers

(p.s. it goes without saying that i have a mirror copy of the production server on local where i test all updates before doing on live ;)

[ergophobe]

I take the site down for a few seconds or I use git.

The reason I do not take the site down for a few seconds with drush is because if the upgrade goes bad, the site might be down for minutes, hours, or permanently borked.

So option 2 which is way safer is
- update the site on your dev platform with "drush up" or whatever method you like
- run any automated and manual tests
- commit the changes to git and push to the repo
- merge with your live branch and push to the repo
- log into your live site via the shell
- pull the new version down on the live branch
- run "drush updb"

In your case, you're doing the update twice, which is just wasted effort in my book. If you're already upgrading and testing locally, there's no need to run "drush up" on your live server ever.

As an added bonus, .htaccss, robots.txt and any other files normally destroyed by "drush up" are preserved as long as you are not tracking them in version control.

[jamie]

that sounds be far the best solution thanks; but it's difficult for me to implement because my htdocs folder is full of other non-drupal stuff. e.g. 5 separate git repos (for other apps), 100 or so client folders. i suppose i could build a big git ignore file?

no, scratch that, i've just found out i can have wildcards in the gitignore, so something like
# ignore everything
*
# except my files
!modules/
!misc/
!includes/

etc, etc

tks ergophobe, i'll get that set up asap :)

jamie

[jamie]

for future reference this is my .gitignore file to only keep drupal files in version control.
i ignore the sites/ directory, because that is a separate repo for me. i like to keep the main drupal install and the custom sites code separate. ymmv :)

# file: /.gitignore
# ignore everything
/*
# except following
!/.gitignore
!/includes
!/misc
!/modules
!/profiles
!/scripts
!/themes
!/authorize.php
!/CHANGELOG.txt
!/COPYRIGHT.txt
!/cron.php
!/.htaccess
!/index.php
!/INSTALL.mysql.txt
!/INSTALL.pgsql.txt
!/install.php
!/INSTALL.sqlite.txt
!/INSTALL.txt
!/LICENSE.txt
!/MAINTAINERS.txt
!/README.txt
!/robots.txt
!/update.php
!/UPGRADE.txt
!/web.config
!/xmlrpc.php

[ergophobe]

Why do you want to ignore non-drupal files? You should be managing all code under git, not just drupal.

Ideally, you should be able to do a git clone, set up your DB and have a mirror of your existing site. Boom!

In your case, you're even ignoring the /sties directory, which is the one more than any that you want to track, since all your customizations are in there. Typically the only things I ignore are

.htaccess
/sites/default/files
/sites/*/settings.php

Maybe a few others, but generally I do even track images and similar assets that are part of the theme, just ignoring user-generated content.

[jamie]

i have the /sites folder in a separate repo

otherwise i have at least 5 other separate repos within the root directory (and at least another 50 other folders with static html). i prefer to keep them separate, rather than have one massive repo. that way i can also give limited access to a particular repo if needed (i don't think you can limit git access to subdirs within one repo).

[ergophobe]

Got it. I think if you had a repo where people had access to the repo but not certain folders the repo included, odd things would happen.