By Anonymous (not verified) on

I don't know if this is the proper Forum for this topic but here goes...

How do people setup Drupal environments for a development effort with multiple team members...coders, themers, etc.

What is the typical setup? What environments to you create (DEV, TEST, PROD)? What is the best strategy to migrate code and data schema changes across these environments? Is there a dedicated resource on the team that just does migrations/deployments.

We're using SVN and I'm trying to figure out how to use that properly with Drupal...one needs to keep track of Drupal core, contrib modules, custom modules, custom themes, data schemas, etc.

How do coders and themers work in conjunction? We thought that an approach might be that once the code is stabilized, then the themers can do their work, but what about concurrent code dev that will impact what the themers are doing?

I'm trying to wrap my head around this.

Thanks.

⋅ Categories: Drupal 5.x, Drupal 6.x, Drupal 7.x

Comments

szb100’s picture

szb100 commented

I have the same issue.

In my case we have a small team of 2-5 people working on a voluntary basis. We are not developers (although we do have general IT development experience), we mainly download contribs, configure them, tweak the site settings through the admin console, maintain a custom theme, and upload module updates.

I'm at a loss as to how we can do this effectively and efficiently. Can anyone help?

matalo’s picture

matalo commented

Well here is the way I did it:

Every developer has a copy of the site in their unix home directory. Apache is set up to serve two virtual servers for each developer from their home directories. One is "live", one is "crashburn"; something like ".dev.crashburn.example.org". Through the drupal multi site system, the name of the folders in sites/ remains the same for all users("example.org"), so an svn checkout will work for anyone immediately with no modifications.

I did not want to deal with the hassle of some complicated database merges when developers made changes to the database, so their "live" sites all share the same database on the server. If they want to do development which will not drastically affect the database then they can do so on their live site, stuff like theming. Having their own subdomain keeps their development breaking other devs sites.

With the other site, "crashburn", the devs have their own database. Through some trickery in settings.php, I detect the subdomain that is being accessed and select the devs own private database accordingly. I provide a shell script to copy the live database over their own crashburn database within a few seconds. Devs can do work on crashburn which may break the database. I do not provide a way for them to put their modified crashburn database back onto the live site. Too much hassle.

Anything in sites/*/files/ is ignored in SVN. An rsync job runs every few minutes and distributes the latest version of all files out to all devs.

Devs do all testing in their own live site. Two other environments exist, staging and production. Again through trickery in the settings.php file, I detect where the site is being accessed from and choose the right settings. The system knows if it is running in test / staging / production and chooses the right database. By doing this we know that running an SVN checkout in any environment will give a site that works straight away with no changes needing to be made to any config files.

szb100’s picture

szb100 commented

Thanks for the comments Imaboyo
Is there anywhere that I could reference which suggests best practice for maintaining a drupal deployment in SVN?

matalo’s picture

matalo commented

I'm not aware of anything myself, made it up as I went and I'm happy with the way things turned out.

adavidow’s picture

adavidow commented

We have different teams working on different areas of the site that are being developed at different rates, sometimes over months.

The trickiest part is capturing all of the configuration settings and how they change--do people just diff the changes in the tables for each module as they configure those modules? How do you best capture changes in content, including comments to various pages, as the production version of the website evolves over time independent of development?

Is anyone yet doing this in git?

dcmouyard’s picture

dcmouyard commented

Use the Features module to export your configurations to code. You can then use version control (I use git) to keep track of your configuration changes.

I don't put content in version control. I use database backups in case something happens to the content.