views:

494

answers:

3

Hello all,

I'm a bit lost, one of my developer co-worker is doing a drupal website, that is doing special pages, custom logos, custom hierarchy etc. His work is scattered in database tables (it looks like CCK create tables), database rows (texts, image links etc.), static files (pictures, PDFs ...) and maybe some PHP (custom module).

My problem is to get his work in the git repository and being able to deploy it on various servers in a consistent way, like I would do with traditional developer work (let's say J2EE). One of my constraint is avoiding raw SQL because we might deploy the same code on various RDBMS. But if I have to, I'll relax this constraint.

I can't find a module that does that out of the box, do you have any pointer I could have missed on the drupal website ?

Thanks for your help,

Nicolas.

+4  A: 

The Features module might get you were you want to go. It allows you to export various site and module configurations. The exports are in the form of a custom Drupal module which you could then store and manage via git, and subsequently roll the features out to other Drupal sites.

http://drupal.org/project/features

more info (and a screencast) on the module:
http://developmentseed.org/blog/2009/may/29/making-and-using-features-drupal

ashtonium
Thank you, this is really interesting, and with such a name, I didn't look at it before. I'll try that today.
nraynaud
Too bad, a Features doesn't embed database content. For our problem at hand it doesn't help, but it will help us on other developments aspects, thanks.
nraynaud
By "database content" do you mean the content of nodes? (The configurations that Features exports are stored in the database by default as well.)
ashtonium
Yes, the nodes.
nraynaud
Not sure why you'd need to store node content in git, Drupal has it's own revision system for nodes. But there are a number of node export/import modules that might fit the bill.
ashtonium
In my point of view, the interesting thing in versioning systems is being centralized every artefact is versionned at the same rhythm.I'd like to have a artefact that in one click extracts all that's different from a bare installation an put in on the drive in (ideally) a collection of files (so that we can diff the stuff a bit), and with another click I can re-import it to a bare installation.
nraynaud
+2  A: 

Using Features along with Context is very powerful. Context lets you create a "section" for your site. It's best illustrated through an example:

Lets say we define the "Forum" context as anything with the url of forums/*. Context lets us say: "I want to show these three views in the right side bar, only when I am in the "Forums" context.

Now, using Features, we can create "module" define by the context. So, we will end up with a module called "youSite_forums", which will include all the views, blocks, etc. that was define in your Forums context. It also will determine the correct dependencies, as well as Content Types used in the context. All will be bundled up nicely in a module.


As for versioning content such as node, you can user either Node Export, or just do a DB dump using Backup and Migrate. We use these occasionally, but we never have every node versioned in SVN.


Links:

Features

Context

Backup and Migrate

Erik Ahlswede
+2  A: 

You might also want to look into services & deployment. Deployment uses services xmlrpc server to to transmit most drupal data from one site to another, or in your case, your devs installation to a staging installation.

http://drupal.org/project/Services

http://drupal.org/project/deploy

As for a method to "deploy it on various servers in a consistent way" look into Capistrano with railsless-deploy. It's so simple to setup some tasks, I use it to deploy all my drupal sites.

http://www.capify.org/index.php/Capistrano

http://github.com/leehambley/railsless-deploy

unn
the point of my settup is that there is no direct connection between dev and staging, it should pass by git between them. So that I can go back in time, I have the same "version rhythm" for files, nodes and theme etc. my whole "application" is a lot more than a drupal module, and I don't really trust drupal enough to make it the main component of our offering. I'll just "integrate" to it.
nraynaud
Probably just easiest to go with context and features then. At least you can store the feature in a repo and enable it as you please.
unn
Although this is always the problem you run into with Drupal... you have all these views, blocks in the database, how do you consistently get them from one place to the other.
unn