Websites – live, dev, and test
September 27, 2017
Long ago, websites were fairly static things. You would create a website, push it live and be done for months, if not years. Advancement in technology has changed all that. Websites today may change weekly, daily or even more often. The constant flux creates certain challenges, risk and stress. The good news: proper process and planning can keep things running smooth as silk.
I typically have at least 3 sites for every client – live, dev and test. Dev and test are completely password protected, for SEO reasons, and are typically subdomains (dev.example.com and test.example.com). Having 2 copies of the live site gives us tremendous freedom and comfort. It is also a part of my 3, 2, 1 backup strategy. Not to mention – brace yourself – I use Sublime text editor and Transmit SFTP. My pipeline is dead simple and from the stone age. Why? Simple is easy and simple works.
By having dev and test, we have 2 working copies of live. They may be out of date, but they are there. Suppose someone crashes the main site. We can always go to dev or test and have something to restore or just look at. If something small breaks or is deleted, we can go to dev or test, see the differences and correct our missteps. These restoration approaches are far more surgical than the panic-stricken, “mash the button to restore entire site from yesterday”, method. In this same vein, we can (and should) develop and try solutions on dev.
The dev site is a playground with zero consequences. We can sling around code and get it working the way we want without impacting the live site. It is a great place to try out new techniques. I recommend running updates to things like WordPress core or plugins on dev first, so you can spot errors before they hit production. Dev is a fantastic safety net for jr. developers and clients alike. There is no better confidence builder than practicing in a safe place. Regardless of what you use dev for, having that sandbox mitigates risk and reduces stress.
Dev sites are not all that uncommon, but most often they go away after a refresh or a major initiative. I keep them around at all times and keep them up to date. They are just handy to have on tap.
What is less common, is a test site. A test site is key because we need to get items from dev to live in a smooth and efficient way. If you think of dev as a branch then moving changes to live is a merge. When we have what we like on dev, we can practice the go-live process by migrating things from dev to test. If migrating items from dev to test goes well, we then migrate changes from dev to live.
Sometimes, going from dev to test, we will run into a snag or two. This dry run really smooths things out. Everyone involved has tremendous confidence things will go well because we practiced. If we want, we could practice over and over. The point is, you uncover those unexpected things in a safe way.
It can seem a bit extreme. Not every single change is made on dev and tested on test. It all comes down to your specific skill level and what you are trying to do. It is a judgment call, but I err on the side of safety. I am a Murphy’s Law type of guy. I like to plan for failure so that we avoid it. Insert your favorite cliché here.
Something to note – using this dev to test to live process slows things down in a very good way. When a client wants something, you say “Sure. We’ll get that going on dev.”. It helps everyone to understand we need to 1. develop 2. test and then 3. deploy. Everyone will have better expectations on timeline. Done right is far better than done right now.
This approach may appear more expensive but it often saves cost. For one, clients can try things out themselves. They may need some help polishing and pushing live, but clients often can grind through the initial work. Also, confidence breeds efficiency. If you are not scared to make a mistake, you drive forward boldly. Because we discover hiccups in a sandbox, we avoid costly mistakes on live.
Tips for using dev, test and live sites
Always host all the sites in the same place. You want live, dev and test to be as similar as possible. Keeping everything hosted in the same place helps reach this ideal of similarity. It also makes things particularly easy when all of this is on the same server. You can copy and move things around with ease.
Subdomains work particularly well because you do not need to own more than one domain name. You can create dozens of replica sites without having to increase cost. Assuming you have a wildcard SSL, you can have them all covered under one certificate.
Speaking of SSL certificates (TLS) – make sure your dev, test and live sites all use https. If you are using http (because you are reading this article via time machine), make the change to https.
I always use relative urls when I build. Relative urls will move from one subdomain to another, from this domain to that, and seamlessly transition from http to https. BTW, a relative URL is like this /contact/ as opposed to this https://www.example.com/contact/.
Keep dev and test up to date. If dev and test are not an accurate clone of live, you are kind of missing the point. Plus, for any reasonably sized site you can clone it in 5- 15 minutes. Practicing the cloning of sites has a beneficial knock-on effect. When you can clone a site in 15 minutes, you realize how not-scary go-live is.
Laboratory, best-case, and real-world scenarios
Live, dev and test are one side of the development coin, focused on keeping the environments the same. The other side of that coin, is all about testing in varied environments. Let’s explore that, while we are at it.
If you are optimizing sites for WCAG, speed, text-to-code ratio, responsive, etc – it is important to engineer for the laboratory but test best-case and real-world scenarios.
The laboratory is the best you can possibly do. This is an HTML document, structured via semantic HTML, and with zero CSS or JS. My version of this is my quality standards document. It is a real-world web page in the wild. This is my foundation and my pinnacle. I will not create a document more streamlined than this nor will I produce something that is more performant. All new development starts here and is thoroughly tested. Because it is 1 HTML document – that process takes virtually no time.
Next, we need a best-case scenario – and ideally a few. I recommend all sites have, at the very least, the following “required” pages: /linking-policy/, /privacy-policy/, /sitemap/, /terms-and-conditions/ and /website-accessibility-statement/. The pages scream out as best-case scenarios. They will have anywhere from 0 to hundreds of links, and vary considerably (most likely) in word count. They will not, however, have any layout or media. Testing these pages for WCAG, speed, text-to-code ratio, responsive, etc gives you the best-case scenario that your pipeline can possibly produce. These “high water marks” will not be as good as your laboratory scores, but they should be pretty close. If you are suffering significantly the moment you go from laboratory to best-case scenario, you need to rethink your workflow.
Getting into the nitty gritty… The sitemap will highlight link spacing on mobile. The varying word count is exceptionally helpful for explaining to clients how text-to-code ratio works. You can literally tell them a number of words to aim for, for their specific site, for a given set of text-to-code ratio targets. The accessibility statement might be 500 words, the linking policy closer to 350, but the privacy policy should probably be closer to 1,500. Look at that, we have a neat little linear matrix of text-to-code ratio … in a best-case scenario. Having this data is tremendously helpful once you cross into real-world territory.
Outside of the best-case scenarios, I typically look at an article, an “average” page, and home. As you move through this progression, your performance will almost certainly drop a little bit more for each step forward. The key, is to understand how, where, and why. The more data you collect and the more often you test, the easier it becomes to understand what changes or additions will impact what and by how much. Understanding is one thing but putting that knowledge to work is another.
If you follow this strict and disciplined approach to your build, while remaining honest and transparent with your client – conversations change dramatically. You can raise a flag of awareness before getting too deep in a “problematic” feature. My classic example is contact forms.
Contact forms require additional work for WCAG compliance. More likely than not, you are going to use some sort of cookie-based anti-spam. The addition of cookies requires a cookie notice and opt-out mechanism. The entire package will require additional scripting and CSS – meaning your performance metrics will take a beating. Let us not forget, you will need an SMTP to get those contact form submissions delivered to inboxes.
If you walk a client through all these knock-on effects, they sometimes change their mind. They might move the requirement from contact form on every page to contact form on 1 page. This certainly resolves some of the performance issues. If you can get the client this far, you might be able to convince them – contact forms are not the effective – especially in the face of the larger “penalties” we must pay.
Here is another classic example – the dreaded slider. I admit my bias here and openly state – I dislike sliders. They are lazy design. They are ineffective. A much more persuasive tactic to “negotiating” a slider is text-to-code ratio. Test the text-to-code ratio of the page, pre-slider. Install the slider and retest. You will no doubt find the text-to-code ratio took a dive (not to mention the performance tank). You can then add in lorem ipsum until the text-to-code ratio returns to pre-slider levels. At this point, you can inform the client, in order to maintain the 25% text-to-code ratio minimum we are targeting, this page needs X amount of dense, highly engaging words added. Most clients find writing content hard – which is why they want the slider in the first place. Showing them how adding a slider makes the page objectively worse, from a performance and text-to-code ratio perspective, can sometimes change their tune on having it.
The real key, for my nickel, is this – have the data on your side and discuss things with the client. If you take the time to run tests in your laboratory, the best-case and real-world scenarios, you have a mountain of data to show and speak to, so that everyone one is making informed decisions. If you practice this enough, you can proactively scope and price for these kinds of things. For the more uncommon requests that have knock-on effects, I use the following idea, it works like a charm.
// Some Code i Wrote Pricing and Project Management Methodology
var KPImatrix = ‘| |Need|Don’t Need|\n’ +
‘|-|-|-|\n’ +
‘|Want|Must|Could|\n’ +
‘|Don\’t Want|Should|Won\’t|’;
while (project.isAdvancing()) {
data = observeTelemetry();
if (data.indicatesNewIdea()) { applyKPImatrixAmendment(data); adjustBudgetWindow(data); }
maintainAbsoluteHonesty();
}
project.Reconcile( KPImatrix, BudgetWindow );