You, Drupal and Version Control

Posted by jaymiejones86 on October 13, 2010 at 8:35pm

Hi Everyone,

I was just pondering to myself in regards to version control with your Drupal websites.

I am actively using GIT for my projects but have been thinking about how to version control the entire Drupal website. I came up with a few interesting questions, well interesting in my eyes.

Version control your theme, custom modules separately, and then version control your whole website with ignores for the custom modules and your theme directory.
Version control the whole Drupal site. Eg: theme, custom modules etc all under the one repository.

I have arguments for both on this. if you version control everything, then say if you made changes to a theme, committed them, then made some updates to say Drupal core, then committed those. What happens if you need to revert changes just from your theme. Wouldn't this cause some issues with the updates that you had committed. Maybe its just from jet lag from 3 days of travelling to get home without sleep.

If you version control your theme, custom modules and then the rest of the Drupal site, is this unnecessary, or could it be seen as useful for segregating these into their own repositories.

Let me know your thoughts.

Comments

Drush Make + git

Posted by skwashd on October 13, 2010 at 11:26pm

I would recommend keeping your custom modules and themes in git repositories and make them available on a features server as releases, either internally or to the world. Any mods to existing modules should be kept as patches, which you include in the make file. Just reference the stuff contrib you need. I would recommend keeping other 3 party modules in your own git repo, purely for security and to ensure they don't disappear. Then all you need to track in the project repo is the make file.

I'd recommend reading mig5's blog post on the subject. It also talks about Aegir, that bit is optional.

My approach

Posted by larowlan on October 14, 2010 at 12:25am

My approach (not saying it is best - just adding my 2c):
*Custom themes and modules in subversion
*Contrib modules ignored
*Files directory ignored
*CCK etc exported to code via features
*Views exported to custom modules
*Patches to contrib modules in repo (if needed)
*All config changes, variables setup etc made in code via hook_update_N functions in custom module so it propagates nicely between two (or three or more) servers. New modules installed that way as well using drupal_install_modules().
This approach served me well for http://www.my-greece.gr where there were four environments (alpha (private), beta (public), testing (client), live) - never once needed to pass around the database.
For other projects where nodes needed to be migrated as well (eg staging -> live) I've used node_export from the command line using drush. It works very nicely with files support too.
Hope everyone is well

What skwashd said

Posted by rimian on October 19, 2010 at 4:27am

If you commit the drupal core and contrib modules, you'll end up with mostly redundant code in your repo. There's half your problem.

I set up git to ignore everything in the root except sites/ and the drush make file. Then, I use some more ignore rules inside sites/ to ignore binaries and contrib stuff.

It's much faster to keep your site up to date and in good shape if you don't have to manage redundancy.

hmmm good point

Posted by jaymiejones86 on October 19, 2010 at 6:59am

Hmmm good point rimian, but in doing that, if you do do some kind of code update to core and or contrib modules and something breaks (I know drush makes backups of the files) would it not be better to have a backup of your core and contrib codebase aswell?

Re: hmmm good point

Posted by skwashd on October 19, 2010 at 7:21am

If you are using Drush Make to build platforms rather than just using is as some kind of distributed version control system, then you won't have this problem as you will have the old platform still there. Drush Make supports, and best practice recommends, specifying version numbers for everything in your .make file. This stops everything working perfectly in staging, then 10mins before you deploy to production one of the modules drops a BC breaking release on every one.

Great point skwashd. Cant

Posted by jaymiejones86 on October 19, 2010 at 8:50am

Great point skwashd. Cant believe I missed that. It makes a lot of sense to do that in that fashion.

A different approach

Posted by jrsinclair on October 22, 2010 at 4:58am

I have a slightly different approach, since I use version control as a backup system as well. I've written up the way I do it in some detail at: http://www.opc.com.au/web-development/drupal-release-management-drush-an...

In summary, I put everything into git, including a dump of the database. This way, if something goes very wrong, I can restore the entire site from a backup in seconds. I do it this way because I often work in restricted environments where access to the internet is limited. Obviously it won't work too well for large-scale, high-performance sites, but for a site with a couple of blogs and a few static pages, it works fine.

Doing it this way also means that I can restore the site to any point in its history without worrying about breaking stuff.

Interesting to see the

Posted by jaymiejones86 on October 22, 2010 at 6:09am

Interesting to see the different ways of using a VCS to work with Drupal.

At the moment I personally GIT theme, custom modules and the rest of the Drupal system separately and use RSYNC to update the server.

Does anyone else have any other methods they use?

problems when contrib or core is hacked

Posted by amaree on November 1, 2010 at 11:03pm

I agree with skwashd however i have the unfortunate role in life of having to clean up Drupal installations alot of the time. What i find when im asked to look at a site is generally contrib modules / core has been hacked and not patched. When im in that phase of cleaning up a site i treat SVN (in my case not GIT) as a back-up, this way as i am trying to rebuild the site the proper drupal way and i break something i can roll back to the last back-up before the f&*k-up ;)

Once i get things into a Drupal way (ie hacks into patches, contrib module hacks into wrapper/glue modules) then i set-up what skwashd is talking about. I have not had to much experience in Aegir as it is to instable for me to install for my mainly corporate clients. However Drush is a must on all Drupal installs in corporate world i feel. Maybe for small sites it may be overkill? however once you start to know Drush it does start to make Drupal life alot for livable :D

However when it comes to Drush/Ageir in Australia then skwashd is your man #my2cents ;p

Drush for small sites

Posted by jrsinclair on November 1, 2010 at 11:14pm

I'd have to agree that Drush is an essential tool, even on small sites. Even if all you use it for is to apply security updates to modules then it's still totally worth the effort of installing.

Drush Love

Posted by jaymiejones86 on November 2, 2010 at 12:02am

Could not ever go back to the time where I was not using Drush. I don't know how I went about development and maintenance without Drush.

Im trying to get the company I work for to start using Aegir but they are nervous about adopting it even after me setting up example Aegir systems and showing how well it works and how much time it could save us. Oh well, Drush only will have to do.

Im going to try out the makefile approach on a larger site soon and see how that goes.

Great Info!

Posted by justclint on January 29, 2011 at 8:14pm

Man, Im happy I found this post. The info has helped me greatly. I would like your input on something.

I dont version control the settings.php file but Ive run into a site which has additional settings changed in that file like url_base & default maintenance theme.

Now knowing that the settings.php has custom changes other than the db authorization Im wondering should I version control it or not.

Assuming you dont just version control the whole site, how do you guys handle settings.php in version control, or do you? I guess the same goes for other files like .htaccess, robots.txt, etc...

Thanks!

.htaccess, robots.txt and

Posted by gordon on January 31, 2011 at 9:54pm

.htaccess, robots.txt and other I just put under version control as generally they are always the same across the board.

However settings.php I maintain on the site independently of source control, for 2 reasons.

it has passwords in it, that I would prefer not to get out in version control.
settings.php is normally read only, and can cause problems when it needs to be updated.

If I do have a complex set of settings that I want across the all sites, without having to copy, I will create a site.settings.php and include that in my settings.php on environment.

Gordon.

--
Gordon Heydon

Multiple settings.php files

Posted by jrsinclair on January 31, 2011 at 9:42pm

The way I handle this kind of thing is to create labelled copies of each settings file. For example:

dev.settings.php
test.settings.php
prod.settings.php

I then tell Git to ignore the real settings.php and manually keep the copies in sync with the originals. Since the settings files don't really change too often, it's not usually much of an issue. This way I can get back a copy of the settings files in an emergency, but I don't have to worry about git over-writing my production with development settings whenever I do a push.

Of course, YMMV depending on security requirements.

Thanks Guys!

Posted by justclint on February 4, 2011 at 5:48pm

@gordon: I will do as you mention and just keep the .htaccess and robots in repo.

@jrsinclair: That seems like a great solution with the various xxx.settings.php files. I will take your advice on that one.

Thanks again guys! I still get stuck sometimes working with version control. If I wasn't for Drupal Im not sure when or if I would of ever been introduced to it.

I truly appreciate your help!