Posted by pnijjar on July 7, 2010 at 4:52pm
Is there a best practices document for storing your drupal configuration in version control?
Is it even worth putting a Drupal site in version control if you don't hack core?
Is there a best practices document for storing your drupal configuration in version control?
Is it even worth putting a Drupal site in version control if you don't hack core?
Comments
Exclusions
Makes for a good discussion on the July 15th meeting ...
In many cases, it is worth putting all your www directory under version control (with a few exceptions below). That directory will contain custom themes, custom modules and contributed modules too. You will benefit from version control here. Updating from 6.16 yo 6.17 (for example) can be tracked in version control.
One benefit is testing/staging/production. You can update your testing server, test out things, then updating the staging server (if you have one), and finally pull the changes after they have been well tested to the production site in one command.
Whatever you do, think about what to exclude from VCS.
Do not include the "files" directory, since it is large, contains binary files, useless to version and tends to grow over time.
Think about whether you want to version control settings.php, since it has passwords in it. If this is a private repository, on a per site basis, it may be OK. If it is a code base that will be deployed on many sites, then don't put this file under version control at all.
In other simpler use cases, VCS can be a burden. A simple test site that is a copy of production, and a database dump with a backup before upgrading may be all you need.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Khalid's comments are right
Khalid's comments are right on.
There is a definite benefit as soon as you have more than one Drupal site. Even without custom code, if you're managing more then one site you'll start saving time with VCS.
With a single site, if you're customizing themes or writing your own modules, VCS becomes very important.
As for the eternal question about configuration in VCS; your best bet is to use Features and Strongarm to codify functionality. Users can still modify things in the database, but at least you'll know if they deviate from the exported versions. At the least, I suggest exporting Views and dropping them in VCS.
Lamp Stack
Judging from my experience with other frameworks, its necessary to have an understanding of the internals and workflow. In the Lamp stack that would mean: what is in the php files and what is in the mysql?
Another point would be: Do you really want to retrace the steps? ... as in one forum post to another. Probably not necessary.
Jon
Full database is impractical
What I meant when I replied was limited to the files under www for your site (minus the files directory and possibly settings.php).
I don't advocate putting the entire database dump under version control, except under limited conditions.
One such condition is a database dump of a "starter skeleton site", not a live production one.
As deviantintegral says, there are better ways of doing it, even in such use cases (features, ...etc.), but depends on the amount of customization you want to do.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
database under version control
I can think of situations where storing snapshots of the database in a VCS is useful. At least during initial dev.
In my current situation, I am developing multiple sites and have a staging server. I have auto deployment set up and one of the deployed directories is "sql" above www where I have a script to check for new versions of the dump and if one exists drop the current staging db for that site and replace with the new one. That way there is next to no work involved in keeping staging synced. It's just a matter of exporting the db whenever enough changes have been made to noticeably break the sync, and putting that dump in the "sql"directory and committing.
Of course in production the amount of content in the db may make this a ridiculous process - not necessarily useful aside from having a backup.