With the midpoint of the summer passed, it's time to evaluate how things stand so far and then looking forward to what should be done next. The first three objectives I listed at the start have been accomplished.
- A command-line toolkit for automatically downloading specific versions of Drupal code and building the site-code tree; consisting of:
1.1 A schema for describing a Drupal site deployment with the following information:
a) CVS revision of core .inc and .php files
b) CVS revisions of core module files
c) Name and CVS revisions of contrib- modules
d) A .profile for module and site configuration
1.2 A parser which takes an input file with the schema in 1.1 and generates a PHP script which download required files from CVS and builds the site directory tree
You can download the toolkit from http://www.drupal.org/project/DAST Phing has been hugely beneficial, providing the basic framework on which to build DAST but these three tasks took a lot longer that I thought they would. A lot of the design issues I think I have figured out though, and the next set of tasks should go a lot faster. The next 3 objectives are being able to configure the server where Drupal supposed to run:
2 A command toolkit for automatically generating a set of web, database and application server configuration files for hosting a Drupal site; consisting of:
2.1 A schema for describing a Drupal web server, database server, and PHP configuration with the following information:
a) Type of web server to target and required configuration for Drupal
b) Type of database server to target and required configuration
c) Enabled PHP extensions and php.ini settings
d) Any enabled application server to target and configuration
2.2 A parser which takes the input file in 2.1 and generates a PHP script which writes a complete set of server configuration files and directives
Configuring PHP shouldn't be that difficult; the build script simply insert inserts ini_settings inside the settings.php file where Drupal's custom settings normally reside. MySQL settings are normally stored in a standard PHP ini file format so it shouldn't be difficult to insert or modify settings defined there. Configuring the web server (Apache in this iteration) may come down to simply copying the desired *.conf or .htaccess to etc or web directory. I couldn't find any projects which allow you to write programatically to Apache conf files without doing the parsing yourself, although the Perl module Config::ApacheFormat has the ability to parse Apache conf files.
Now having Phing is one thing, but being able to use it effectively and simply is something different. The dast-patch build file ran to more than 400 lines. Clearly that's not something the average dev/tester is going to want to wrestle it to create one of their own. So after I'm done with the server configuration bit, I want to turn my attention to making build scripts more user friendly:
Common functionality will be factored out into base build files. There will be site-fetch.xml, site-install.xml, and site-configure.xml base files. These base build files are designed to be reused in other build files like site-patch. Another thing I long planned to do is write a set of custom tasks and tasks for Drupal-specific operations. For example although Phing ships with its own CVSTask, this will be subclassed to produce a DrupalCVSTask. DrupalCVSTask contains defaults specific to accessing the Drupa; CVS repository and living in DAST build files, so the build file writer needn't spend time punching in these parameters over and over again.
I've seen three definite areas where using build files can make a big difference:
0. Verifying the pre-install environment. Some basic tests to ensure the user's web/database/php server environment is setup to run Drupal can can make the install process a lot easier for many users. From personal experience, A common frustration on Windows, is that there are a lot of factors that can prevent Drupal from running - IIS is a complex beast that is dependent on things like NTFS permissions, ISAPI mappings and virtual directory configuration...a build script could run unit tests to verify things like the location the user wishes to install Drupal is a valid virtual directory, has the proper NTFS pemissions, has the PHP ISAPI configured, and that PHP itself is able to run and has the recommended extensions (mysql) and settings (like memory_limit).
1. Installation profiles - mentioned before, can automate downloading modules and core and performing pre-install configuring/verification of user's environment
2. Automatic patch testing - When a patch is applied the build script can instruct Drupal to run unit tests to test/verify the patch's behaviour from the simpletestauto test suite
There are many more places I think DAST can be put to use, in both development/testing and end-user user; they all derive from being able to using a formal build language to stage a Drupal site with access to all the functionality that PHP and libraries llike simpletest provide fro pre-stage, and post-stage tasks.
I've been thinking about the interface to DAST and about possibly writing a true Drupal module. I've been thinking about it and I don't see any reason Phing can 't run when invoked from a web server - this can be beneficial to people who don't have CLI access but still want to run build scripts provided for them. But Rok and I agrree that a Drupal UI can be left till after the SoC period.
So for the next week-and-a-half I'm going to concentrate on implementing the server configuration functions. Once this is done, I'm going to refactor the code to make it more reusable and easier to use by wrapping common funtionality in base build scripts and custom tasks. Hopefully by that time the project would have gained some traction in the Drupal community, and people will start looking at writing their own build scripts. At this point I'm going to start writing build scripts for the use cases. The final three objectives are going to be writing build scripts to clone and start a virtual machine image, so that the previously created build scripts can stage the Drupal site to this virtual server.