Evolving the deployment and development model
Mark Birbeck
I've been doing a lot of work over the past couple of weeks on the
questions of deployment, performance, and the development cycle.
I've tried out a few ideas, and also taken a look at what other
projects are doing, and one thing that seems to be getting clearer for
me, is the idea that the run-time code needs to be 'built' from the
source, and it is this which is zipped up, and made available for
'deployment'.
You might think that this is the model we have at the moment, but it's
not really. Our roll-up file tends to be regarded as something that is
generated to gain some extra speed, and this step is done by someone
else, not the developer. Also, the location that the roll-up file must
be placed into, and its relationship to other files needed at
run-time, is not clear.
But in my experiments, I have a build step that creates a concatenated
version of the library *and* a concatenated version of the unit-tests,
and then 'deploys' these files into a specific directory, which is
structured exactly how authors would need to have it on a server. This
directory is where testing takes place.
Although it adds an extra step to your development process -- you need
to run a build to get the new scripts, before you can test them -- I
feel there are many advantages to doing this. (And for anyone who is a
C, C++ or Java programmer, that extra step of doing a build before you
can test, will feel very familiar -- before you know it, it will be
second nature.)
The main advantage I see to using the deployment directory for
testing, is consistency -- what you are testing is the same as what
will be deployed.
First, you are testing the rolled-up script, rather than the many
small files that make up the script. I don't think we've had any
problems so far with files being missed out, or whatever, but I know
we've had a lot of problems with the loader itself, when one part of
the code tries to use something that isn't yet ready. So testing with
the 'compiled' file should eliminate a lot of that, since the YUI
loader is simply not needed.
But second, I think this technique introduces consistency in the sense
of testing in a proper 'deployment' directory structure. I know people
have had problems with trying to deploy the rolled-up file to servers,
because it wasn't clear which of the various files (such as HTC, XBL,
and so on) the library needs. Authors have usually ended up just
copying the entire UXF source to get it working! However, if we create
a build process that copies the concatenated scripts, plus any
supplementary files, into a deployment area, then it quickly becomes
clear when something is missing.
Anyway, this is still probably a week or so away from being in a
position to show (hopefully I'll be able to do it on a telecon soon),
but I thought I'd just give everyone a heads-up, in case any thoughts
come to mind. The key idea I'm flagging up for people to start
pondering is this idea of a compilation step, which essentially means
that our script files become 'source' files.
Regards,
Mark
--
Mark Birbeck, webBackplane
mark.b...@webBackplane.com
http://webBackplane.com/mark-birbeck
webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)