Question

I’m having trouble covering all the issues with doing Software Configuration Management on a CMS (specifically, Joomla!). I’m writing custom templates, of course, but also custom modules and components. These websites and apps are for clients, not in-house.

I want to actually version the configuration of the site, not just the code of its templates and components, because I want it to be ready to ramp-up for fixes, or transfer to someone else, as quickly as possible. Right now, that means storing a full Joomla! install for each site in SVN, including the installed versions of components and templates, and storing actual database exports. For components, I also keep the ‘packaged’ version of the code (see below). I don’t usually bother for the templates, since you can just drop it into the Joomla! install and it works.

The problem with this set-up that I’m currently debating is in custom component development. In Joomla! (and most other CMSs) extensions are typically deployed using a web installer – you can’t (at least initially) just drop the files in a certain folder, since DB changes are required. The Joomla! installer system provides for DB and file migration with install and uninstall hooks, so it’s a pretty reasonable system for deployment.

Right now, I either: 1) work directly on the installed component, adding and changing files and then manually copying them to the packaged version of the component, or 2) work on the packaged component and use the installer to actually view the results. This option just takes too long usually, but it does have the advantage of keeping the code ‘releasable’, especially in regard to DB migrations.

In either case, the changes are duplicated to both versions of the files before check-in, and the duplication seems like a smell to me.

So, does anyone else do this? Are there better options?

Answer 1

‘1/’ should be ‘kind of’ the way to go

When you have the word ‘packaging’, that means you do not version one, but two ‘components’ (set of files)

• one ‘development’ component: quite large, with every files you need
• one ‘distrib’ component: quite small, with a few of compressed files in it.

It involves:

• an automatic way to build and version that distrib component (by compressing those files and storing them)
• an automatic way to copy that distrib component (representing the compressed version of your packaged version), uncompressed it and rsynch-it with the test or production platform.

That way, you do not simply ‘duplicate’ changes, but keep track of an actual full configuration:

• ready to be deployed on another platform
• or used to rsynch a current deployed package.