Exploring website go-live techniques

July 13, 2021

Even among developers, new website go-live is often considered a pretty scary thing. The problem lies in a lack of understanding of how the internet works. Most folks think about the internet in terms of … grab a device, some magic happens, and then internet comes out. The hesitation surrounding go-live lies in that magic, “black box” bit. Let’s demystify what is happening to better understand go-live methods.

Side note – websites are created in various ways. This example will look at how a WordPress website works. The details vary a bit from site to site, but the general idea is the same.

When you request a website, like example.com, the first stop is DNS. This is like the phone book of the internet. The DNS records indicate where a website is hosted and do so via an IP address. So, example.com is hosted on a server with the IP address 93.184.216.34, and that server is the next stop.

The server has various files and directories. We start at the .htaccess file which is a general configuration file of sorts. For WordPress, this file says, load the index.php file. The index file in turn says to load the config.php file (a WordPress-specific configuration file). The config.php file determines what database to use. The database looks up various things, including the theme. Finally, based on the content of the files and the database, a web page is created and sent to the user. It looks a bit like this:

Nerd Alert! – server-side caching bypasses much of the “looking up” process. Instead, the server will simply send an old copy of the webpage it made previously. This is how server-side caching makes WordPress (and other server-side processing sites) run much faster.

Once you understand these steps, it starts to make sense how new websites are launched. We make a change at one of the various handoffs and a new website is “live”. One common method is to change the DNS settings. A new website is hosted on a new server, and we simply update the IP address in the DNS settings. When someone “looks up” our website, the new website is served via the new server. Keep in mind, the old site still exists on the old server, until we remove it from the server. Eventually, one would cancel the hosting on the old server that would be that.

While there are some advantages to this approach, there are various disadvantages as well. Changes to DNS take hours to spread across the internet. This makes go-live a slow process and one that does not occur at once for everyone. Rolling back this kind of go-live is a bit messy for the same reason. Additionally, changes to DNS can impact more than your website, such as your email. This is an example of using a hatchet when a scalpel will do. It gets the job done, but it is a bit clunky.

The primary reason one might use this method for go-live, aside from not knowing any other, is if the current hosting is insufficient. While I do occasionally come across this issue, it is rare. In these instances, I prefer to move the current site to the new hosting, and then build a new site. More on this in a moment. More often, though, I find developers use the DNS method because they are dependent on a particular hosting environment. If a developer always builds using a particular hosting environment, they will require you to change hosting. It is important to note, a change to DNS is not the only way to launch a new site, it is just one method.

I am not particular about hosting and will build the new site on your current hosting, so long as it is sufficiently powered for the expected load. As mentioned above, if we need to upgrade the hosting, we will, but will do so before building the new site. This splits the site changes across multiple phases and is a more stable approach (has less disruption).

How then, does one have two websites on one server? Subdomains. The new site is sequestered in a directory, such as dev, and is unique and different from the current live site.

When leveraging multiple subdomains on one server, go-live has numerous options and they all have benefits. One option is to move all the files out of the main directory and into a “hold” directory. We then move all the new website files from the dev directory and into the main directory. This will launch the new site in minutes not hours. Similarly, if we need to roll back to the old site, we move the files around and everything is back to how it was before. This is how I launched sites for years. It works well and I never had an issue. I then realized, there is an even more efficient method.

Because I always advocate for having 3 versions of a site (live, dev, and test), I am well-versed in moving sites around a server. I realized, I did not really need to move all the files, I just needed the config file and the theme. Everything else, as far as files, was the same and could be left (as long as we planned accordingly). The databases are all on the same server regardless, so they don’t get moved. I started playing around with just moving the theme over and then simply updating the config file to reflect the new database and new theme.

This approach to go-live has a wide range of advantages. It is even faster and simpler than moving all the files around. Go-live takes seconds, not even minutes. Once the theme is uploaded, it is just changing 4 lines of code in a single file (config.php) and the entire new website is live. Rolling back is just as simple. I can even build a new website while the current one is rolling down the road. I can develop an entirely new website, while a client is creating new content on the existing site. It is all really, really cool stuff.

Nerding out on go-live technique aside, the point is this: go-live should never be scary. Even in the “worst-case” scenario, where we change DNS and wait a few hours for the result, go-live is not necessarily a permanent state. Proper go-live has roll-back procedures in mind and the current site is not lost to history. Given a more sophisticated go-live strategy, we can all but assure nothing will go wrong. Anyone who tells you there is anything to fear in regard to go-live is either not competent or selling you a load of smoke and mirrors.