Save yourself some time, reduce your frustration, remove code deployment risk and improve your insight by using our technique to quickly test and deploy new web analytics code on your site without the need for staged testing.
Fear driven motivation ...
Quite frequently we needed to test site updates on a staging server for fear of breaking the production site, upsetting customers and losing revenue. This seems like a really good idea, except that when the files are pushed live things don't always happen quite as expected. Staging sites are never the same as production, we've seen perfect copies have issues with cookies due to the different domain, poor version control, different asset location and other network issues like load balancing amongst a range of other problems, the bottom line is they are never the same, period.
In addition to the testing issues, we also need to deal with the fact that assets like Javascript are cached by some browsers. Code roll outs are not immediate, but dribble out over a period of up to a month as browsers invalidate their cache. This is a scary proposition for people relying on the analytics data, especially when frequent updates are required.
Efficiency driven motivation ...
In addition to this, for many of our clients (e.g. banks) we have rare deployment windows as far as 6 months in the future (yes this is not an exaggeration) and aren't allowed to test code outside their building. We have other clients where we need to send them code and wait for a testing response when they can allocate the resources. The feedback loop becomes very slow and sometimes very minor code issues can cause significant deployment delays. The loss in revenue and general inability to find answers to key business questions in a timely manner cannot be underestimated.
Our background is in analytics and strategy, so we're usually dealing with Javascript files for tracking purposes, but the same issues occur with all asset based code updates. We want a simple means to test and deploy new code without making any on page changes or requiring testing in a staging environment. Maybe i'm lazy, but i don't want to test the same code twice! This initially sounds a bit ambitious, but it's actually pretty simple.
The solution ...
We use a single controlling file to include all other Javascript assets. The single file has the ability to switch between different Javascript file versions based on the existence of a cookie (created from a URL parameter when testing is required). This single file is also utilised to control the file version of the asset files without making any on page changes.
Advantages
- No on-page changes are required for Javascript updates EVER
- All updated files roll out instantly to everyone, there is no caching lag. Roll backs are just as easy.
- Testing on the live site can be performed without ever affecting a single other user. Staging sites are not required.
- Testing can be performed remotely (wherever the production site is accessible).
- Risk of web site down time or customer irritation is greatly reduced.
- Time to go live is significantly reduced.
- Development costs are significantly reduced.
- Javascript file names can include a version number, this greatly reduces confusion around version control.
Implementation
If you know Javascript and you're looking for an example, check out below. If you need more explanation, then drop us a line.
A. CONFIG
- Production server base location (e.g.
www.client-site.com/js/)
- Test Server A base loca
tion (e.g.
www.your-live-test-site.com/client-folder/js/)
- Test Server B base location (e.g.
www.client-site.com/js/live-test/). Maybe they want to test too!
- File version (or name, e.g. scode-v1.js)
B. DEFINE INCLUDE FUNCTION and OTHER BASE FUNCTIONS
These functions include setting and retrieving cookies, reading URL parameters into variables and including other javascript files.function gqp(name){name=name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");var regexS="[\\?&]"+name+"=([^&#]*)";var regex=new RegExp(regexS);var results=regex.exec(window.location.href);if(results==null)return"";else return results[1];} function setCookie(c_name,value,expiredays){var exdate=new Date();exdate.setDate(exdate.getDate()+expiredays);document.cookie=c_name+"="+escape(value)+((expiredays==null)?"":";expires="+exdate.toGMTString());} function getCookie(c_name){if(document.cookie.length>0){c_start=document.cookie.indexOf(c_name+"=");if(c_start!=-1){c_start=c_start+c_name.length+1;c_end=document.cookie.indexOf(";",c_start);if(c_end==-1)c_end=document.cookie.length;return unescape(document.cookie.substring(c_start,c_end));}}return"";} function include(filename){document.write(unescape("%3Cscript src='" + filename + "' type='text/javascript'%3E%3C/script%3E"));}
C. ADD LIVE TESTING FUNCTIONALITY
Some example code is shown below. The test URL parameter we're looking for is called "datalicious". So a URL like
http://www.client-site.com/?datalicious=test will trigger the code to include from the test location instead of the production server. The default production code base is stored in a variable called "datClientCodebase"
var datURL=document.location.href.toLowerCase();datTest = gqp('datalicious'); if (datTest == 'test') { setCookie('datCookie', 'test', 1); }if (datTest == 'client-name') { setCookie('datCookie', 'client-name', 1); }datCookieValue = getCookie('datCookie');if (datCookieValue == 'test' || datTest == 'test' || datCookieValue == 'client-name' || datTest == 'client-name') { // This will use the test files on your server folder livetest if(datCookieValue == 'test' || datTest == 'test'){ var datCodebase = '//www.your-server.com/client-name/js/livetest/'; }else{ // This will use the test files on the client-name server folder livetest var datCodebase = '//www.client-name.com.au/js/livetest/'; } } else { // Your server will use the production dir (this is done so you don't need a different file version on your //site), otherwise the client code base is used, which is the default normally if (datURL.indexOf('your-server.') > -1) { var datCodebase = '//www.your-server.com/client-name/js/'; } else { var datCodebase = datClientCodebase; }} D. INCLUDE THE FILE
The following line of code takes the base file location and the file name (version), combines them and requests the desired file.
include(datCodebase + datScode); E. TRIGGER
Now the file has been included, if there are any analytics functions, like with the Omniture scode, or google analytics page tracker, this part of the code can decide when these functions are executed. Normally we have conditions here so the function can be triggered at either the top or the bottom of the body.
F. CALL THE CONTROLLING FILE
Your web sites can now include this base file, but we recommend you use a cachebuster to ensure any updates you make the to base file propagate in a timely manner (we use 24 hours, but you can set to whatever you want). A code example is shown below, this would appear on all site pages:
<!-- BEGIN CACHE BUSTER --><script type="text/javascript"> var cacheBuster="";var cbd=new Date();var cbm=new Date(); var cby=new Date();cbd=cbd.getUTCDate();cbd=cbd.toString(); cbm=cbm.getUTCMonth()+1;cbm=cbm.toString();cby=cby.getUTCFullYear(); cby=cby.toString();cacheBuster=cbd+":"+cbm+":"+cby; </script><!-- END CACHE BUSTER --> <!-- BEGIN INCLUDES --><script type="text/javascript">document.write('<scr'+'ipt type="text/javascript" src="//www.client-site.com/js/datalicious.js?cb='+cacheBuster+'"></scr'+'ipt>')</script> <!-- END INCLUDES -->Email Hamish at hogilvy@datalicious.com if you need help with your implementation.
Email this post
Comments [0]