tags:

views:

31

answers:

1

In my last Drupal project we were 5 people doing coding and installing new modules, at the same type our client was putting up content. Since we chose to have only one server for simplicity there were times were many people needed to write to the same files like style.css or page.tpl.php or when someones broken code would prevent others from working

Are there any best practises for a team that works with Drupal? How can leverage code repositories or sandboxes?

+2  A: 

A single server may appear to give you "simplicity", but what it gives you, as you've experienced, is utter chaos -- and you were lucky if it didn't result in unpleasant and hard-to-reproduce, harder-to-fix crashes. Don't settle for anything less than a "production" server (where your client can be working -- on content only -- if they like minor risks;-) and a "staging" one (where anything from the development team goes to get tested and tried for a while before promotion to development, which is done at a quiet and ideally prearranged time).

Second, use a version control system of some kind. Which one matters less than using one at all: svn is popular and simple, the latest fashion (for excellent reasons) are distributed ones such as hg and git, Microsoft and other have commercial offerings in the field, etc.

The point is, whenever somebody's updating a file, they're doing so on their own client of the VCS. When a coherent set of changes is right, it's pushed to the VCS, and the VCS diagnoses and points out any "conflicts" (places where two developers may have made contradictory changes) so the developer who's currently pushing is responsible for editing the files and fixing the conflicts before their pushes are allowed to go through. Only then are "current versions" allowed to even go on the staging system for more thorough (and ideally automated!-) testing (or, better yet, a "continuous build" system).

Basically, there should be two layers of defense against such conflicts as you observed, and you seem to have deployed neither. They're both essential, though, if forced under duress to pick just one, I guess I'd reluctantly pick the distinction between production and staging servers -- development will still be chaotic (intolerably so compared to the simple solidity of any VCS!) but at least it won't directly hurt the actual serving system;-).

Alex Martelli
Nice answer, as an architect on a Drupal project, I'd like to add that one should really go with Git. We have been using Subversion and it has kicked us in the butt a few times. Drupal.org itself is moving to using git, so it is a good step for developers to as well.
nowarninglabel
Yes, good answer. This pretty much how I've worked collaboratively on Drupal sites. We currently use Subversion and it works nicely.In the past we haven't used a staging server. Instead we just develop on our own machines using a Drupal installation that closely matches the production server (same modules, same database). Every now and then we grab sql dumps from the production server to keep the content in sync with our own installations.
In our case, we find it useful for each developer to have his/her own server. It's trivially easy to do with XAMPP and MAMP. That way developers can do things that break Drupal (temporarily) without causing problems for anyone else.When code seems to be stable, it is checked into SubVersion and tested on the staging server (that is similar to production).It sounds like an extra step, and an extra layer of complexity, but we really find that it works well.
Graham
@Graham, +1, I agree your practice is even better -- I didn't realize it was "trivially easy to do" (the sysops who did it for me in the past made it sound like a lot of work on their part!-) which is why I didn't think of recommending it as a first improvement.
Alex Martelli

related questions