5

I have just begun development on a Drupal 7 site in a team of three and I am trying to determine the best practice for versioning. This is causing me a bit of a headache because much of the work on a Drupal site is made in the database as well as the code.

I have installed the 'Features' module which allows for exporting views, content types, rules, ect. into an XML file which can them be included in the checkin, but we need to ensure that whenever we add a new module it is enabled on our machines before a feature is imported in case there are dependency issues.

When modules are added to our local machines, both code is added and the module is enabled in the database, so checking in the code to our git repo takes care of half of the problem, but we are left with the possibility of crashing each other's site if we fail to contact each team member notifying them of the manual changes to be made.

I have searched but I have failed to find a module or any other solution to this problem. Ideally there would exist a module that would create an XML file of which modules are enabled on one machine, then after checkin a second machine would be able to read this file and ensure that the two sites were in sync.

Has anyone found an elegant solution to this problem?

Improve this question
3
  • Just an idea will be to use the "demo" module to generate snapt shots of the DB on the remote machine that can be reloaded using the same module on the local machines.
    – Emil Orol
    Commented Aug 8, 2012 at 4:53
  • Drush and a shell script could make for an interesting solution. Even versioning and module verification could be worked in with a little effort.
    – Citricguy
    Commented Aug 8, 2012 at 5:42
  • For content updation previously we were using a common mysql server so that all 4 of us would be using the "same DB". Would this work out for you ? You have to change $db_url in settings.php to a common dev mysql server.
    – GoodSp33d
    Commented Aug 8, 2012 at 6:39

1 Answer 1

Reset to default
3

This is how we are working:

  1. Keep as much as possible in code. Features strongarm and other modules are helpfull here. Often we figure out the configuration variables of the modules and put them into settings.php by hand.
  2. Things like enabled modules are left to the DB. We maintain a central copy of our db in GIT. If someone adds a new module, he is responsible for taking this DB, adding the module and pushing a new copy to git together with the new module code. The backup & migrate module is very handy here.

An other alternative would be to develope against a single central DB. The disadvantage of this is that you will likely face situations where one developer trashes the DB and therfore the work of his colegues as well. You could set up a cron job taking a DB dumps at regular times to make sure you don't loose to much in such a situation.

Improve this answer
1
  • Testing this initially on my own, I would say it seems to work alright. I will wager a guess that were going to run into a handful of initial annoyances and likely a few long term ones too (things like the temporary directory on different operating systems which is stored in the DB in a blob). If I had the time (hint hint to anyone with some extra time...) I would write a module which takes out just the necessities from the database, and writes them in a file, checks for the file's existence and executes it if it's there.
    – Godwin
    Commented Aug 9, 2012 at 2:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.