Recently, at some project, we planned to dedicate some time to improve our deployment and build packing process, so we can use the solution in future projects.
What we decided to do:
- make a pack of all the Java scripts and CSSes, to reduce the page load time
- make a static content versionable
If first is quite a common practise, I wan’t to tell more about the second point, on example.
We use an automatic deployment system. So installing of new software version can be done easily and takes little time. So, for example, if we faced some serious bug with CSS, something is very bad with User Interface and the problem is with some external CSS directive.
If we will just change solve the problem, locally in those CSS file, make a build and upload it to the server we’ll have some users, with loggined sessions and cached CSS files in browser. We have uploaded the fixed version of CSS, but user still see the old one, with bugs.
The same problems can arise with all the static content(java scripts, CSS files, images). So we decided to make that content versionable too. Main purpose is to force the browser to load new version of those content, when we deploy new version.
That is how we decided to do that:
if we change all the paths in HTML, to static content with some unique postfix, such as, for example “styles.css?ver1.2″ or “logo.png?ver39″ or even “logo.png?UUID-UUID-UUID-UUID-UUID”, we’ll force all the browsers to reload the files. But, we have found that actual CI build number(not UUID or revision) works best for us, because it some bug arises we can know for sure, in what build is it, to make a bug fix and deploy new version.
I automated the process making the unique URL postfixes for static content while packing build, ready for deployment, by using the Apache Ant and sed. Here is the example:
<exec command=“find ${build.dir} -type f -exec sed -i ’s/BUILD_NUMBER/${build.number}/’ {} \;“>
</target>
That command search for all the files recursively in the build.dir folder, and replaces all the matches “BUILD_NUMBER” to build.number value.
To make this command run your view templates have to look like that:
<link rel=’stylesheet’ href=‘http://realitydrivendeveloper.com/wp-includes/js/thickbox/thickbox.css?ver=BUILD_NUMBER’ type=‘text/css’ media=‘all’ />
So it will still works in development environment.
There are different ways of setting ${build.number} variable, depending on your repository vendor(if you want to tag it by revision number), continuous integration server(by using its build number), generate some unique string(UUID) and assign its value to the ${build.number} variable, or even to install ${build.number} value manually, but it is not desired.
For, example, here are some ideas:
http://www.zorched.net/2006/07/20/getting-the-revision-number-of-your-subversion-working-copy/
http://code.google.com/p/bamboo-ant-tasks/
You can reduce code duplication by using the wrappers for outputting the links for static content(images, javascripts and CSS).
Tags: apache ant, build, css, Deployment, javascript, packing, sed
