[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
"hidden".

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
environment:

Using CVS to maintain a Drupal website
http://drupal.org/node/93966

R. Keeping Your Local and Remote Sites Synchronized
http://drupal.org/node/120617

Drupal development server configuration
http://www.garfieldtech.com/blog/drupal-dev-server

K. Moving Entire Drupal Site with Databases
http://drupal.org/node/120627

Migrating Database Changes From Development to Live Websites
http://drupal.org/node/199771

Drupal Performance Measurement & Benchmarking
http://drupal.org/node/282862

Drupal with safe mode enabled and open basedir
http://drupal.org/node/82223

More than one Drupal site on one machine
http://drupal.org/node/274

Transforming a default table names installation into a prefix table
names installation
http://drupal.org/node/195758

How-To: Virtual Hosting with Drupal
http://drupal.org/node/80472

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it



More information about the development mailing list