Web deployment with compressed files

Question

Short Version

When using file compressors like YUI compressor, what is the proper procedure for deploying your website, so that you don't have to mess with compressed files during development time? Should there be a compression script as part of the release process?

Long Version

I just joined a project where we use YUI compressor for our JS and CSS files. I ran into some chunks of code that to me, seemed to smell very badly. I'm wondering if there is a better way to do this.

I think that while working on the code, developers should be free to work with the uncompressed files, and have the website still work and reflect their changes as they go. Then the altered css and js files can be compressed at release time. That's not quite how it goes here.

Basically, on of our core php pages does a check on PHP_SAPI, and if it's command line, runs the compressors. This consists of running an exec on git log and then some sed magic to get the current revision number (to be used as a css and js file version), then proc_opening the yuicompressor, run that on the files, a few more execs to add the new files to git... and then some voodoo reaches into the php file itself (yes, it's self-modifying) and changes a $version variable declaration to the new revision number. This variable is used to include the correct css and js files.

When I first checked the code out of our repo, the website ran locally, but there was no css. I was told by a colleague that I needed to run a shell script that invoked the incantation above. This took about half an hour of tweaking file permissions before it succeeded.

Does this smell as bad as I think it does? How can we get rid of this as a development step and have it possible to just include the regular uncompressed files during development? As it is now I can't make changes to said files and see them immediately. The problem with doing it at release time is that the includes would have to change to the compressed files at the time the files are compressed. It seems like that would require scripts that modify the code as well. Any ideas?

Answer 1

Dude :) I can help you with this - I (mainly) ported YUI Compressor to .NET because I needed to make sure that .. when we deploy our code .. the public servers had minified/combined css and js. .. This could apply to any language/deployment scenario, despite my scenarios being .NET / TFS specific.

The trick is to make sure that the source files during your development are not touched at all. Never. It's only when you push the code from your own development (aka Localhost) machines to others servers (ie. Dev/Test/Uat/Live-Production) should the css/js be minified and/or combined.

It's too hard to work with minified and/or combined css/js while working on your localhost dev machines .. ESPECIALLY if you're working on the UI experience .. ie. doing javascript/html/css.

So what do we do? First of all, we need to have a deployment solution. For .NET we use TFS to deploy our code to servers. But there's plenty of other options ..like i think Ruby On Rails peeps can use Rake and add a YUICompressor task in there.

With TFS, we have Continuous Integration going on .. so whenever some code is checked in, our system more or less does the following (which is the crux of this post).

.. into a temp location ...

• Grab latest code
• Compile latest code
• Minify and/or combine any js or css .. and these newly created files go into the temp location where the code was compiled.
• Publish this code/website from this temp location to the desired web server (dev/test/uat/prod.. etc).

What is crucial in that list is the fact that all this is happening in a temp location. Not over your current development folder. You don't want to mess with your main source files.

So if you can tell us

• where your code is stored (source code). I think you said GIT?
• what language (php?)
• and most importantly, how do you get the code from your source control to the live server?