[development] best pratices, test environment, patch review: clues how to make easier to contribute

Ivan Sergio Borgonovo mail at webthatworks.it
Thu Aug 14 12:53:10 UTC 2008

There are a lot of good tools for helping coders and reviewer.
There should be a lot of experience in building up a dev environment
*and* a patch review environment spread in the community but

If I had to put up a dev/review environment now I would:
* install drupal HEAD
* install coder devel modules(?)
* fill drupal with some data using devel
* backup

* update from cvs
* restore db connection setting
* apply a patch
- check if any schema change
* test (benchmark?)
* report
* restore db

Still this look very naive and I think there are a lot of tools that
could help without getting into module frenziness  and a lot of
details that could streamline the process or setup that may hide
some problems.
There is not a compact knowledge base of several techniques that may
make more profitable for people that already maintain drupal sites
to contribute to core and contrib. I think that most developers are
still applying common wisdom and their own hand made recipes.

code coverage, deploy, drupal automated staging toolkit, drush,
simpletest and auto test???

If tests are already automatically made on submitted patches,
preparing a testing environment isn't so critical for a patch
reviewer, but it could come handy for a developer.

If I had to improve the above naive method I'd start from writing a
script that given a patch url:
* update from cvs
* restore db connection setting
* apply the patch

Second thing I'd do would be to replicate the simpletest environment
and start testing the patch.

Then I'd choose a set of "important modules" and see if patches or
HEAD breaks them.
I think this looks a bit more tricky and may require some rcs
wizardry especially if I've my modules to test too.
Another thing I'd like to learn to do better is how to maintain
modified drupal core, supposing I submitted patch waiting and I'd
like to check if they still works when I update to HEAD/review a
patch and mix svn (or any rcs of choice) with drupal cvs.
A DVCS could come handy here... but... that's not the point here.

The material about how to put up a dev/review environment is sparse.
Something that may be interesting and I would like to read more
about or see them grouped or add some glue so that it would be
possible to guide people to a more rationalised dev/review

Using CVS to maintain a Drupal website

R. Keeping Your Local and Remote Sites Synchronized

Drupal development server configuration

K. Moving Entire Drupal Site with Databases

Migrating Database Changes From Development to Live Websites

Drupal Performance Measurement & Benchmarking

Drupal with safe mode enabled and open basedir

More than one Drupal site on one machine

Transforming a default table names installation into a prefix table
names installation

How-To: Virtual Hosting with Drupal

Ivan Sergio Borgonovo

More information about the development mailing list