[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