It's Friday afternoon, your developer messages to say they've just pushed out a "quick fix" to your website. Twenty minutes later, your phone rings - your checkout page isn't working.
It's a scenario that plays out more often than anyone in the industry likes to admit. Not because developers are careless, but because without the right process in place, even a small, well-intentioned change can pull a thread that unravels something else entirely. The more a site grows (more products, more integrations, more customisations) the more threads there are that can be inadvertently pulled.
There's a better way to do this. And when it's working properly, you'll barely notice it's there.
What makes up a website
At its very simplest a website is comprised of various assets - HTML pages, javascript files, stylesheets and images. A more complicated site will have a database. A site that runs on PHP (think Magento, Laravel, Wordpress) will also have various code files.
The files and the database will reside on a web server, which hosts the site and responds to requests for it. So - put simply - if you want to change the files, you need to connect to the computer that's got the web server on it, and upload new versions of the files.
The old fashioned way
Back in the olden days (by which we're talking 20 years ago) the only real way of changing a site's files was to do it manually, over FTP (File Transfer Protocol) - it was slow, and since the new version of the file would overwrite the old, it meant that you would generally rename the old file first, and store lots of old backup copies. This meant that rolling out a lot of changes was problematic - you had to keep track of which files you'd changed, and roll those out (or roll out an entire new copy of the site, but remember, FTP was - and is - sloooow).
Version control to the rescue
Version control has been around for years, in various guises, but the most well-known and widely used is GIT. In essence, it tracks every change ever made to a codebase, so nothing is ever lost, and you can always see what was changed, when, and by whom. It also allows you to maintain separate branches of the same codebase (one for use on the site, one for testing) and move changes between those branches easily, without having to unpick what's been changed. Finally, it allows multiple people to work on the same code at the same time, only requiring input if someone's trying to merge in changes that would impact on changes that someone else has made.
Staging sites
Because hosting is (relatively speaking) much cheaper than it used to be, it's easy to have a copy of your main website set up as a staging site, on to which changes are made and checked before they're rolled out to the live site. They can also be used to allow clients to try things out without fear that they may accidentally press the wrong button and delete everything.
You can see, therefore, a sequence starting to form - using version control, you can have two branches of your website, the production branch and the development branch. Your live, customer-facing, website tracks the production branch, and your staging site tracks the development branch. Changes that are made first go into the development branch, get reviewed on the staging site, and when tested and approved, the changes are merged into the production branch and pushed out to the live site.
This process is the start of the all-important pipeline.
Automated testing
One of the most powerful things a pipeline can do before deploying code is run a suite of automated tests which verify the site is behaving as expected.
These can range from a simple "does this page load without errors", through to tests that simulate a customer journey - adding a product to a basket, entering delivery details, completing a purchase.
If any of those tests fail, the deployment stops, and the broken code never reaches your staging site, let alone your live site - it's the difference between finding a problem in a controlled environment at 2pm on a Tuesday, and finding it when a customer hits your checkout at 11pm on Black Friday.
How we work
At Status 218 we lean heavily into a suite of tools to set up pipelines for our clients' websites that - in many cases - our clients never see.
Almost all the sites we manage are version controlled through GIT. Almost all of them have staging sites set up. We use a fantastic bit of kit called Jenkins for deployments that runs all the necessary commands (whether on a live or a staging server) when a new change is pushed out that seamlessly updates the site. Loki aggregates all the logs from their site and Grafana shows them to us in a clear way. Pushover keeps us informed of the good - builds running, tests succeeding - and the bad. Kuma monitors all the sites we host and their availability on the web. Vito administers the servers themselves.
That's why, when we push new code live for our clients, it's boring. We've already done the hard work. And long may that continue to be the case.