Posted: Wednesday 29th September 2010
Having mentored many customers through go-live scenarios, I thought it was time I shared my general experiences and advice. Some of the advice has a Contensis slant, but it can easily be adapted to most go-live situations. I would also recommend doing a quick 'Google' for go-live documentation and ideas of a more general basis, as I certainly do not believe I have covered absolutely everything!
For some general pointers there is a good article on smashing magazine or another good check list on a blog I stumbled upon.
Get the date right and set the expectation and scope early.
Whatever the deadline or the situation, one thing that is required is preparation, as this will remove virtually all the stress and potential risks from any go-live situation.
Identifying the scope of any project is absolutely imperative, and with any deliverable whether it be an entire new site or just an enhancement, you should identify the requirements and scope early with realistic timescales. This is an entire subject in its own right, but needless to say, if the scope is not identified clearly and signed off by all the stakeholders, the path to a go-live can be a rocky road.
When you have identified you plan, allowed for contingency time and to clearly sign everything off - allow at least 2 weeks after completion of testing to actually get the system live.
The start of this 2 week period should be your internal deadline for being ready to go live. Having this date and sticking to it, is very important, as it gives you the chance to put the new system live early internally or for certain parties in a production environment, without the pressure of the whole Internet. If you do have a problem in this soft-live period, no one is going to get sacked over it, and there is time to sort out any issue properly, without making potentially quick distorted decisions just because you are under pressure of having a live system.
Testing any new implementation is absolutely key. Ideally a full test script would be created, that can be run either on an automatic or a manual nature.
This script will be important moving forward, as it will allow you to test any changes to the site, as they are made to ensure there are no regressions and that everything works as expected when new changes are introduced.
Testing in general is a whole subject in its own right, but my recommendations are:
Create a test plan.
- Automate this plan where possible, so it can be run at any time. (there are lots of tools available on the market to help with this)
- Define supported browsers and test in each of the browsers
- Test the site with other dependant servers disabled, and ensure the effect of such changes does not prevent the entire site from working.
- Force errors, and ensure your error handling is configured to show friendly messages to users.
- Ensure forms are part of your test coverage, they are often forgotten, and a simple SMTP change between environments is usually the problem.
- Test the HTML with validator tools such as the W3C Validator, Total Validator or the Contensis QA service if you have this.
- Finally when you have made all the content and functionally tweaks, or earlier if you choose execute a load test. I would recommend loading twice as many users as you expect, if not more.
- And don't forget to test your print stylesheets!
General advice before go-live
If you are moving to an entirely new site, or even if you are just re-branding, it is important to ensure that your old urls are still use-able.
There can be issues over link equity with search engines such as Google, but secondly we have user experience issues. I'm sure you don’t want users who have bookmarked pages, ending up at a dead link just because the redirects haven't been set correctly.
There are a number of ways of preserving old urls, and again this is a subject that I could spend hours going into, whichever method you choose, ensure the urls are set to carry out 301 permanent redirects to the new content that has been created.
Large migration scenario
If you are carrying out a very large migration from a non Contensis system, probably the most sensible option is to create an export from Contensis of old vs new urls.
When our import tools run, it is possible to configure the tools to fill in a meta-data entry of Original.URL. This can be used to create a very simple mapping of old vs new urls.
When the export is done, you could use the url rewriting functionality built into IIS7+ or you could use a tool called ISAPI Rewrite by Helicon.
Either are sensible, and the approach depends upon which suits your needs better. Personally I prefer the disconnection of the Helicon tool, and the fact that it does not interfere with your web.config (causing a site restart every time you change a record) but Helicon is paid and IIS7 is free (Once you have paid for windows).
Small manual migration
If you are carrying out a small manual migration, then it may be worth simply using the alias functionality in Contensis to add an alias to any page that wants to host old content urls. Simply add the alias through the Properties tab of any content item in Contensis.
Check your Live Site early
Contensis has a notion of a preview site, which can be used to see changes to content before they have been approved. When you are working with Contensis for the first time, or even for Contensis veterans, it is possible to forget to check the site on Live, and simply keep checking the preview (test) site.
My advice is use your Live Site for QA and testing, and the preview site purely for reviewing small changes. The main problem is that people forget to authorise certain pages, and only realise hours before go-live, which can take time to deal with, if proper approval processes are in place.
Normally the result is that people choose to bulk authorise all content, but again this would have ideally been done within the bounds of work flow, which will ensure better quality normally.
If you are not familiar with caching, and you are a Contensis Administrator, I would suggest you become familiar.
Contensis has a method of enabling caching very simply. To put caching into perspective, on load tests we have done, an Asp.Net site with caching enabled can serve 800 page requests per second, whereas a site without caching can server as little as 8.
Using the default config for caching is fairly easy in Contensis, all you need do is change the setting “Contensis_Caching_StandardPageCacheDuration” to a value greater than 0.
Typically most customers choose to cache pages for a number of hours, or in one customers case over 24hrs. Don’t worry, if your page changes then the cache will invalidate automatically, and for pages that include lists of dynamic content, such as news or events for example, we can configure a different cache setting 'Contensis_Caching_StandardListCacheDuration'.
Our cache set-up can also be used by developers, so if you have a control that needs to set cache to x seconds (even 0 or disabled) you can do with ease, ensuring set-up is straightforward, and you do not need to spend hours on cache configuration.
Bear in mind that with caching enabled, server side functionality will be user independant, i.e John will visit the page and some server side code renders some text “Good Morning John”, I now visit the page, and will see “Good Morning John”. Because of this complication, for personalisation, we recommend taking caching into account early on in a project, so you can develop anything with performance and caching in mind. By the way Contensis does have a default control that allows you to do this, with caching turned on...
I would suggest that it is worthwhile enabling the cache trace (simply change the setting 'Contensis_Caching_EnableTrace' to True). Using this you can ensure that the caching is working as you expect. The trace tells you which controls, are requesting cache, or disabling cache, when the page was rendered, and more.
To view the trace simply view the source and look for the relevant comments in the header.
Contensis Controls have been designed to take caching into account, for example when you vote against an online poll, it will invalidate the cache against the current page with the poll. However, I'm sure you can appreciate this is not always possible, and as a result, when using some controls or other functionality Contensis will prevent the cache.
If you are not actively deciding to use viewstate, then you will be glad to know that 90% of Contensis Controls, do not require it and it can be turned off all together, in fact this site, with the entire control gallery present does not use viewstate at all, we too have disabled it.
Turning .Net viewstate off will save a substantial amount of page load, on some sites more than 100k per page, and if it isn’t being used then this is just a waste of time and bandwidth!
As with caching, if you are going to disable it, you need to be prepared from a technical viewpoint to test the change, and if certain aspects do not work correctly without it re-enable it on those areas, or change the relevant control to work.
Contensis Forms definitely do need viewstate, but this can be enabled by simply adding the following to the Page_customCode section of a sub-template, and dragging this sub-template into the form, or the page with the form.
Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs)
Disable Adaptive Rendering
Asp.Net has a feature called adaptive rendering, this feature effectively attempts to standardise output of HTML. What this means is that a perfectly XHTML compliant page, when viewed in a non recognised browser will render invalid HTML. At Contensis we think that when publishing XHTML, it should always be XHTML. Because of this, we would recommend setting the following custom code into the PageLoad event on your base template.
This will ensure that every browser receives the same standards compliant HTML output.
I expect this will become a standard setting in the near future!
Configure Friendly Error Messages
Configuring friendly error messages can be done using IIS and the .Net Web.config. This is not a Contensis function, but a function of ASP.Net and IIS.
The reason we implement friendly error messages such as 404 for page not found and 500 for server errors, is to ensure that your users receive a friendly experience and that any errors do not expose potentially sensitive information.
A couple of potential school boy errors:
Ensure your 404 pages actually produce a 404 status code (this can be checked using a tool such as fiddler). If you don’t check this, every 404 page on your site, may be treated as a real page as far as the search engines are concerned.
Ensure there are no 404 errors on your 404 page, again this can be checked by a tool such as fiddler. This can cause performance issues. Essentially a missing image on the 404 page, will return a 404, which depending upon scenarios, could cause twice as much load on the 404 page.
Bear in mind, that depending upon the version of IIS 404’s must be handled for aspx pages and non aspx pages separately.
Favicon and Robots.txt
You may feel that a favicon is not required, but depending upon the browser, without a favicon, every page may get a 404, which will add to Load on your server.
The robots.txt is very important, if this is incorrectly set, then spiders such as Google could completely ignore your site.
Ideally research this subject in detail, and ensure your robots.txt file is working using tools such as the Google webmaster tools.
Configure IIS for a live migration
If the new site and old site, are on the same server, then it is best to carry out what we call a live migration. Effectively this means that the new site will be live on a url such as live.yourdomainname.com, while the old site still runs on www.yourdomainname.com. At the point of being ready for go live, all you must do is change a single host header, and the new site will be live.
Configuring in this way, gives you an exit plan if you want to move back to the old site, and also ensures, that you can test the site, simply on a different url well in advance.
If you don’t have the benefit of the old site and the new site on the same server, definitely configure the new site on a url such as live.yourdomainname.com, so you can fully test first, before changing your firewall config, or dns settings.
Ensure backup routines are in place
It may sound like an obvious step, but you would be amazed how many people do not think about this.
My advice would be to actually test a full DR exercise before go-live. Where possible simply disconnect the web server from the network, and ensure that you can restore it quickly from backups, and that staff have a fully documented procedure. When the server does fail, which it will likely do for some reason in its lifetime, you will be confident about your approach to resolving the issue.
If you don’t have a backup of the actual site, this is not normally an issue, as Contensis will re-publish the site for you (as long as you have Contensis backed up!)
Standards Compliance & Accessibility
If you think that standards compliance and accessibility, is just important from a perspective of users with impaired sight or other disabilities then think again.
If you create standards compliant pages which are accessible you are effectively making it very easy for search engines to properly index your site. This will help you no end with SEO.
You are also ensuring that browsers will render your content far faster because they do not need to jump into a myriad of different quirks modes, attempting to understand and compensate for the invalid html in your pages.
If you are using Contensis then you can use our Quality Assurance Module to ensure HTML compliance and Accessibility, but if not there are a number of tools available, we use Total Validator from time to time, which is a good all round tool, and is reasonably priced. This tool is designed for a developer though - not end content contributors!
General performance optimisation
Optimising performance is a subject in its own right. We have touched on some ways including enabling caching, but if you have developed bespoke functionality, we would strongly suggest running performance analysis tools such as the Red-Gate ANTS Performance Profiler.
Assuming, that we have no server-side code issues, it is now time to look at any client side implications.
A must have tool which will help you identify problems and improve user download and browser experience.
A great tool for compressing images on your site, it uses some advanced techniques to reduce image size without major quality loss.
A Firebug plugin, which gives ideas to consider.
SEO is an entire subject in its own right, but I have just pulled off a few minor pointers that come to mind, when putting a site live.
- Ensure Keyword saturation is still appropriate.
- Check Keywords and Descriptions on all pages, usually it is a good idea to create a report for this.
- Ensure Homepage title and all other titles are relevant! If you don’t, when your pages are found in Google, they may not make sense.
- Google analytics or another analytics package should be set-up and configured.
- Ensure that homepage does not redirect!, this is not just an SEO issue, but a general performance tweak. Ideally call your homepage index, and this will happen automatically. You can check this by using a tool such as fiddler.
- Check your site in http://www.woorank.com/, sometimes it gives you some pointers, that you may have missed.
- USE SENSEO for Firefox to analyse key pages from your existing site, against the same pages on your new site, to ensure you haven’t missed something obvious.
- Set-up with Google webmaster tools, as this will help you see how people are finding your site.
- Ensure you tick the option to enable a Google Site Map against your publishing server, and submit it to Google using the webmaster tools.
- If you had Webmaster Tools configured before, you may need to re-configure the verification for your new site.
Ready for go-live
If you have followed my advice, then you will have considered all of the technical considerations, and will have a site at this point that is ready for live at least 2 weeks before your actual deadline.
At this point it is a great idea, if not sooner to open the site up on a soft launch internally.
This is a great step, as it will give you the opportunity to get final feedback before live, often managers and directors, may simply ok decisions and options without giving full attention, this has happened many times to us. If someone does make a change at this point, at least we still have 2 weeks to put any change in place!
If any changes are made, it is now time to re-run your test scripts, which is a great chance to test your theory, and ensure your scripts are right.
If you are carrying out a live migration, then the go-live can be done in seconds, if you are relying on DNS changes, then make sure whoever needs to change the DNS drops the TTL (Time To Live) on the domain to a very low number well before go-live. It is normally a good idea to do it 2 weeks before. This way, when you are actually pushing the site live, the propagation of changes in DNS should be quick, and will not take the full 24 or 48 hrs.