Some years back, a client of mine was having issues with her order confirmation emails not being delivered to her clients. 

Testing the website, it looked like the process was suddenly stopping right after the payment confirmation. The webpage was blank, and the logs were incomplete — classic symptoms of a fatal or critical error in the code. 

The problem was that on my local copy of the website, I could not reproduce the issue. Everything worked fine. 

Many hours later, out of desperation and frustration, I decided to a full comparison between my mirror and the live website. If the code and the database were the same, then I had to get the same results. Since that didn’t happen, I had to conclude that something was out of sync. 

The code was in sync, but some of the files were present on the live server that I was missing on my test machine. Those files present on the server were causing PHP to load a different set of classes than what I would have expected. An older version of code was used that was not compatible with the newer shopping cart.

So how did this came to be? 

Eventually, I realized that by using FTP to deploy my code, I would be able to create new files or update existing ones, but I had no idea that some files had to be removed. 

FTP uploads were always additive. Old, unused files never got removed, and sometimes, their simple presence on the server would mess up with how the code was being loaded and executed. And this issue is rather difficult to discover and debug. 

I tried to manually keep track of files that should be removed before the upload. That works with simple, small projects, but it quickly breaks down when you need to deploy tens or thousands of files. 

I realized that with FTP uploads, I was never sure that my local work was in perfect sync with the LIVE software.

Transitory states

There is another scenario where FTP uploads cause issues. 

Imagine a popular web application with a shopping cart. If we need to update this application with some significant changes for plugins or core updates, using FTP to upload the files one by one creates this problem: for a couple of minutes to half an hour, some of the files are new, and some are old. Visitors who are in the middle of using the web app or making a purchase will suddenly notice all kinds of strange error because the code is in a transitory state: old files mixed with new and not always playing along. Depending on your project size and target audience, this may not be an issue, but if you have a high traffic web store, you may be losing money and also looking un-professional if you do updates like this. 

The final nail in the coffin

I have had this happen to me a couple of times. I am fixing something or working on a new feature. I am testing everything thoroughly to make sure nothing breaks. Once I am confident, I push the upload button on my FTP program, and I watch the progress bar impatiently. When finished, I load the LIVE website, and disaster strikes… errors all over the place, even on the home page. 

My mind races to come up with a possible quick fix, but it comes up blank. How I wish there were a “revert” button in my FTP program! It takes me some very long minutes to manually revert the FTP upload with the previous files and get the site working again. And then I am left with this puzzle: it still works on my test machine, it fails on the LIVE server, but I don’t have a way to test why, without breaking the web app while I am doing my investigation. And that is not very professional in my book. 

A faster, safe, better way to deploy your work

Wouldn’t it be nice to have a “deploy” button that would create a perfect mirror of your work on the live server, with no extra or missing files? And wouldn’t it be nice if this would happen with ZERO downtime for the LIVE app and no transient state for the code? And if disaster strikes wouldn’t be lovely to have a “revert” button and get everything near-instantly back in working condition?

Is this even possible? 

Of course, it is. I think everything is possible in the software world!

Enter “Deployer”

In my quest to find a tool and a workflow that would allow for perfect and zero downtime deployment and the ability to rollback my changes in a precise and complete way, I found a PHP tool called Deployer. 

And their idea is quite simple actually, but brilliant. On the live server, you don’t have only one copy of the code, but instead multiple versions. 

When you deploy your changes, a new version gets created from your updates, and when this process is complete without any errors, the web app is instantly flipped to the new code! 

If there are problems, there is a “revert” command that instantly flips the web app to the previous working versions. 

To use “Deployer,” you need a certain kind of workflow. 

My favorite is using git and GitHub to get my new code published on the live server. Using git in your workflow means that you need to be able to run git commands on your live server. Another requirement is the ability to use “composer” to download or update the third-party vendor libraries directly on the live machine, significantly reducing the time necessary to create the new version of the website. 

What this means is that you have to choose your hosting carefully (here is my affiliate link to SiteGround) and to make sure that your workflow is compatible with using a versioning system like git. 

This process takes a bit of getting used to and some setup time in the beginning, but the fast, safe, and revert-able deploys will give you peace of mind and speed up the time you roll out your updates or fixes. 

It is time for the FTP Uploads to Rest In Peace.