13/02/2010

The Drupal Conspiracy aka when team working could be a nightmare...

Can I commit? (Kaare A. Larsen)

written by Carlo Frinolli

You probably got the same issue thousand times.
You probably already solved this easily.

I can imagine your past workflow with our beloved Drupal CMS.
It has zillion of modules, and you get enthusiast of a million of them. You wanted to try them all.

I always do like this. My collegue hates me for that.

And then you obviously have to configure them. So you'll have a whole bunch of modules installed and you most of them don't like anymore.

You're kinda picky guy, right? That module is, I mean, ok... But it's not really there yet. Oh sure, this other module fits you better.

Doing so you're database is messing itself up.

What is as sure as death is that you have not very much time to start from scratch and repeat every single operation. And yes, you're totally not methodical at all, so you don't have any idea of the path you followed to do so.
But you can also be the best structured dev guy on earth and you mistyped something, or misclicked something else. That misclick was a "SAVE" operation. Too bad, and too late.

You want to undo that and you know no way to undo it.

Say you're saving some kind of Drupal block (with titles and contents inside), and you want to deploy it on a production environment.
Or you're and your collegues are concurrently working on a dev environment trying to use the same "versioning" behavior that subversion lets you do. Lots of people working at the same time, and that's it.
But when you're setting up a Drupal View, a Panel, a Block or a Nodequeue, what you do have very few to do with the filesystem, in fact Drupal does its magic not very much on a filesystem, unless you're developing some custom modules - and in this case subversion is simply GREAT.

It does its magic mostly on the database.

Thus the nightmare comes alive.

Demo sets up, demo content, or just one-shot tries, all together in a database, which is simply messed up.
And that's long to do, but anyway easy. Truncating database tables, delete demo contents, and so on.

What if the concurrency I was talking about make the environment blows?

And, as far as I know and type it here, there's no easy solution to "version" the database after every single operation. It's not like committing code.

Come on, you got my point, right? Is there a solution on this topic? If so I'm eager to be insulted for the next year. Literally.
Otherwise we need some brainstorming about that. Very open to that, please just ping me!

And if a solution is not there yet, this could be a GREAT occasion to give back to Drupal community a powerful team dev tool to help community hacking on this wonderful CMS.

comment this post on facebook
 

about the author

Carlo Frinolli

Carlo è la fucina di idee di nois3lab. Un motore appassionato, una guida instancabile per questa società. Creativo e preciso può essere contemporaneamente un sognatore e un lavoratore a testa china.

Skip to Navigation