Changes

The workflow for releasingl releasing code and data from development (possibly done on a local desktop) through test, staging and on to production is both a tedious and critical process. The automation that makes this process successful is the domain of release engineering. There are many aspects to the job, as well as various degrees to which an organization will practice this discipline as a full-fledged domain. Often in larger environments where various teams are working on separate pieces of a system, you will hear the analogy of the "train" metaphor for builds moving through development and test. From the developer perspective, if your project meets certain eligibility requirements, you could get a "ticket" to board the next train which means that your feature or component will be a part of the next build, and you will benefit from that testing and availability.

The 'best practices' described Beware the description at http://drupal.org/creating-drupal-test-sites do because it does not adequately address the issue of release engineering or testing (For example, it doesn't even talk about using mention version control, and the . The database dump and copy is overly simplistic because it assumes that you can take your site offline for the entire duration of your development cycle).

We In a web software system, we need to be sure to account for the at least three aspects of the system:

: [[PEAR ]] (PHP) http://pear.php.net Don't forget that PEAR packager is a build, configuration and distribution tool. http://pear.php.net/package/PEAR http://pear.php.net/manual/en/core.ppm.php