Keeping your Drupal site up to date with Git and Drush

Submitted by jenlampton on August 9, 2013 - 9:41pm

I don't recommend trying to stay 100% on top of all updates for all of your modules all the time. However, when a security update becomes available for one of your modules, you should certainly make that update as soon as is reasonable. And while you're at it, that might be a good time to bring everything else up to date as well. Below is my recipe for keeping modules on my Drupal sites up to date, by using two of my favorite development tools, Git and Drush.

Check available updates. In order to see a list of all the updates that are available for my Drupal site, I make sure I have the Update status module enabled, and then visit Admin > Reports > Available updates. Security updates here will be red, and updates that are not security related (often providing new features) will be in yellow. I usually start with modules that need security updates since those are most important, here I'll choose ctools.
Check currently applied patches. We've decided that we are about to update the ctools module, but before we just delete the current module and replace it with the new one, we need to check and see if we have applied any patches. I track my patches in a PATCHES.txt file, so I open that up and check for patches to the ctools module.
If necessary, Check the issue queue. I do have a patch applied to the ctools module, so I also have a link to the issue in my PATCHES.txt file. I'll just paste this link into my browser and see what's happened since I last applied this patch. From reading the issue I can tell that someone reviewed this patch, but that it has not yet been committed, meaning that I'll need to apply it again (and possibly re-roll it if it doesn't apply cleanly) to work with the newer version of the ctools module.
Delete the current version of the module. I use Git to remove the old version of the module. Using the command line, I'll navigate to my drupal root, and type the following command:
```
git rm -r sites/all/modules/contrib/ctools
```
I do not commit this change yet. (I'll wait till after the module has been updated.)
Download the new version of the module. I use drush to download my modules since it cleanly extracts them for me, and usually puts them in the correct location. Using the command line, (still from my drupal root) I'll type the following command:
```
drush dl ctools
```
Add the new version of the module. Now that we have the updated version, we'll need to add the module back into our version control system. Using the command line, (still from my drupal root) I'll type the following command:
```
git add sites/all/modules/contrib/ctools
```
Even though we use the commands git rm and git add Git is smart enough to track only the changes made to this module. Go ahead and type the following command to see what git will track:
```
git status
```
Commit the update. At this point, I usually commit the update. I do this because I like to see two separate entries in my commit log, one for the update to the module, and a second one for the patch being applied. (This makes it really easy to undo only the patch, should that ever become necessary.) To commit the update, type the following command:
```
git commit -m "security update for ctools module" 
```
If necessary, apply patches. Since the patch we'd been using before the update was not included in the latest version of ctools, we'll still need to apply that patch. (See my previous post on applying patches)
If necessary, commit the patched module. Once the patch has been applied, I'll need to commit that change. If I've rerolled the patch, the link in PATCHES.txt will need to be updated to point to the new comment number where I uploaded the rerolled patch. In this example, I'd type the following commands:
```
git add sites/all/modules/contrib/ctools/.
git add sites/all/PATCHES.txt
git commit -m "comment wrapper template patch applied to ctools module"
```
Run the database update script. It's a good rule of thumb to always run the update script at /update.php after updating a module. I personally like to check the status report (located at Admin > Reports > Status) to see if running the update script is necessary. If it is necessary to run the script you'll see an ugly red line on your status report telling you to run the update immediately. It's not joking, if you see this error, run the update immediately. If you don't - you run the risk of mucking up your data.
Rinse, repeat. YAY! I've updated the first module with security updates. Now I just need to do the same for all the rest. Don't worry, most of your modules will not have patches that need to be maintained, and the process for updating those is much quicker. To make things even faster, checking on update status and running the database update script can also be done using Drush! Let's run through a quick update for token module so you can see how easy that can be.
1. Check available updates.
```
drush ups
```
2. Check currently applied patches.
  (There are none in this case)
3. Delete the current version of the module.
```
git rm -r sites/all/modules/contrib/token
```
4. Download the new version of the module.
```
drush dl token
```
5. Add the new version of the module.
```
git add sites/all/modules/contrib/token
```
6. Commit the update.
```
git commit -m "security update for token module"
```
7. Run the database update script.
```
drush updb
```
Or, do it all at once For those of you who are not faint of heart, you can also run all the updates for your Drupal site all at once - using Drush. I don't do this myself unless I am short of time, and trust that not much has changed on the site since the last time I ran updates. I prefer to have separate commits for each module update, so that if something goes horribly wrong (most of the time it doesn't) I have an easier time debugging the issue. But, here's the shortcut:
```
drush up
```