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

[Jamie Holly]

Something I think should be included in patch review is also database 
load. Check any new/changed queries the patch might make and do an 
explain on it to see if that query is properly using indexes and not 
going to bring the database server to a crawl. I don't know if there is 
a doc page on this. If not, it might be worth adding one, giving a brief 
tutorial on using explain.

On the benchmarking/testing, something I have found to be a nice 
addition to the toolbox is Siege. You can create a list of urls to 
different pages in your installation so you get more of a real world 
test (instead of benching a single page). When developing a site, I keep 
a url.txt file for that site just for this purpose. That way I can 
quickly run a benchmark.

Siege - http://www.joedog.org/JoeDog/Siege

(Also - if anyone has any other suggestions for benchmarking, I would 
love to hear it. I am always looking for new tools to use)

Jamie Holly
http://www.intoxination.net 
Skype:intoxination        Phone: 1-513-252-2919



Ivan Sergio Borgonovo wrote:
> 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
>
>