Within the development environments of MageBridge, we have seen two major changes in our build process: The arrival of Joomla! 1.6 and the decision to create a MageBridge-trial. Because many other extension developers might face changes like this, we thought it was worth a blog on how we modified our build process.
The complexity of our build-process was mainly due to the large number of packages. Inside a development tree (Subversion) we develop the source-code of MageBridge, but this source-code then needs to be wrapped into Joomla! installable packages. Because MageBridge already ships with about 30 plugins and modules, these shell-scripts were very useful when it came to generating new packages when a change was made in Subversion.
The coming of our trial-version and the coming of Joomla! 1.6 made this process very difficult to main: While the ionCube-encrypted packages of the MageBridge Trial only contained a copy of the original source-packages (but then encrypted), Joomla! 1.6 introduced a different problem: We have managed to write PHP-code that worked in both Joomla! 1.5 as Joomla! 1.6, but the XML-files need to be maintained for two different Joomla! versions.
Not only do we need now to develop code in two different environments (Joomla! 1.5 and Joomla! 1.6) but both versions also needed to be supported by both the full-version as the trial-version. Add to this the fact that some PHP-enviroments have bad support for extracting either ZIP or TAR-files, and we came to the conclusion we needed a lot of packages to be generated:
30 (MageBridge modules and plugins) times 2 (Joomla! 1.5 and Joomla! 1.6) times 2 (trial-version and full-version) times 2 (ZIP or tar.gz): 240 packages. And we still want to package our MageBridge-specific connectors in the future, and add more Joomla! plugins and modules as well. You can see the challenge we faced.
Our old build-process was based on shell-scripts. One main script included some smaller scripts. By running the main script, all packages were generated. But adding a new MageBridge module or plugin was a nightmare - due to limitations of shell-scripting (ever played with shell-arrays?). Also, numerous tasks needed to be done numerous times. We came to the conclusion we needed to replace our shell-script with something else.
Johan Janssens from Nooku recommended us before the usage of Phing, and once we started to investigate it, it was definitely a relief: Phing automates the build-process by defining XML-structures. Within this XML, you can define tasks, while tasks can define subtasks and subtasks can define subsubtasks - with full usage of variables that can be defined. In our situation it aided even more, because we needed to copy sources from SVN (without copying the SVN-metadata). Phing even facilitated the encryption of ionCube through a few lines of extra XML-code.
Finally, to finish our overview of the build process we put together, all these MageBridge packages could be built by just running one major Phing task. It takes about 2 minutes to finish off, but the result is right there. The only missing link is how to copy all those packages to the right place, so that they are made available to our MageBridge users:
That, too, is automated by Phing. Once the packages are built, the sources are copied to our FLEXIcontent-based download-section, to our personal Dropbox, to our backup-archive, and so on. Packages are also copied to our Yireo update server, which is used by the MageBridge Update Manager within the Joomla! Administrator: With one hit on the upgrade-button, all packages are updated to their latest version.
The result is cool: Once we have a new feature released, we don't have to wait for the next major release: We just release it right away after testing. Rebuilding things is easy now: For all Joomla! 1.5 and Joomla! 1.6 users, both licensed customers as trial-users.