What are the best practices for a small distributed team which will work on a Drupal project?

Question

after some research, we opted for working with Drupal on our next project and we are a distributed team.

Since Drupal stores (based on what we saw until now) all it's content on a database, how can we, as a distributed team work together on this project? What are the best practices we should take?

We thought about using a shared database server for this task, but it whould simply destroy the performance we should need to get this project going. Any suggestions about that?

Answer 1

Jeremy's answer (+1) is already quite comprehensive. Some additional more practical-oriented advice follows in no particular order.

Disclaimer: this is stuff that works for me. Others might have other suggestion or even disagree. If this is the case I would be superhappy to hear feedback and alternate/better proposals!

1. Make a point that every team member should start his/her session by updating the code AND database. You can easily script all of that with a combination of ssh and rsync commands. I at times create a single script (update-project.sh) that updates the code from the repository and download and import the latest DB from the master server at once.

2. Never forget to call http://example.com/update.php every time you update the code. Run this command on your staging site, after every commit, and on your local machine after every update/pull/checkout.

3. Do any change to the DB via SQL query, rather than with a GUI. That way you will simply have to wrap that query into an hook_update_N() implementation in your yourmodule.install file, and you are safe and sound (if you abide to point #2!) [some gui tool output the equivalent... that's handy too!].

4. Whenever possible, include in hook_update_N() also changes to module settings. This is not possible all the times. When not possible: see point #7 and #8.

5. When creating or modifying a view, export it to a file when finished. Same principle that point #3 but applied to views. This approach has incidentally also the benefit of providing a rollback mechanism in case you later realise you made a mistake.

6. Use a master repository. Don't go for a too much distributed versioning system. Pull and push your code always from the same central repo.

7. Always include a comment in your commit. Especially if some code change change some functionality / API / common logic, make a point to include a warning in your commit message. Detailed info can be put in a changelog.txt file, if needed.

8. When committing, immediately reproduce on the master DB any hand-made DB changes that you haven't managed to include in your hook_update_N() implementation. This is a must if your team members start their sessions like described in #1.

9. Be selective in what you put under versioning. For example: exclude the sites/default/settings.php but evaluate what (if anything at all) need to be versioned from in sites/default/files (are images needed for development? and attachments?).

10. There are some useful contributed modules that can help. Like import/export, which allows you to manage in a repository your CCK and Views or node export that allows you to export nodes and then import them back in another drupal installation.

11. Use the simpletest module extensively. That is a good idea anyhow, but when working in team is a great idea: that way you will be sure your changes haven't broken anybody else's work.

12. Have fun! I love to work in team and I believe one should try to do that everytime he/she can. It's more fun, more learning and above all... better code! :)

Bonus point (does not refer to team development specifically):

• Try not to use your staging server for real content insertion. Ideally you should start creating content only when the code is somehow freezed or use an import routing/module: drupal scatters information across tables a lot, and the system of hooks makes very difficult to track which modules have stored what information where: if you develop on a DB with real data, you will inevitably end up breaking some tables at some point, and you might realise that only the day before going into production. :(

Answer 2

First off, best practices.

You should always consider your live database the master. You can use database dumps to get this live database each member of your distributed team. This ensures that each member of the team is working from the same base.

You should use a a version control system to share your code, so that you are all working from the same codebase but have control over when to merge the code.

Sharing a database between developers, and or sharing a codebase between developers will cause confusion and should be avoided.

Now some more opinion based thoughts

Content for your site should be created and edited on the live server.

You should release the code in a managed, repeatable way. Ideally you should have a staging server to test the code before it goes live.

The tricky part is content and configuration changes. I have advocated that these should be done in update functions in a dummy module. However sometimes this is arduous to do, or in some cases changes can't be done reliably. So there should be a balance, most configuration changes should be done in code, so they are repeatable and can be distributed among developers easily. But for configuration changes which are not easily coded, or which are required outside of a release window you can make them directly on the live server. The important thing is that you can get your code and database into a consistent state across development and live.