Deployment hazards

One giant leap for an amateur-developer

The screen you see above is the homepage of the website of my company. I launched it the day before yesterday. It’s in French, but by all means, have a go at it!

The first version was created in wordpress. The second version in Statamic v2 and this version is in Statamic v3.

Statamic offers a migration tool to, well, migrate sites from v2 towards v3. This tool wasn’t very capable for my site for a couple of reasons. The fact that my v2 site relied on bespoke components calling the Statamic v2 API using PHP 7.3 being a major contributor to that failure.

In short, migrating my site was nothing short of rebuilding my site. Eventually, I’m quite glad I went through the hassle: the site looks and feels better and incorporating Vuex to handle the shopping cart makes it 100% certain that this version is more robust than the earlier version.

After months of thinking, coding, rethinking and refactoring, there it was. My site was really working as expected on my local machine. It was time to “open up to the world”.

Nervous as hell?

Yes, I was. And for good reason. I had to deactivate my former site and upload the new site.

It didn’t go smoothly…

Before I explain my troubles and solutions to them, I should first introduce you to my configuration.

At home, I work with an Apple Mini M1 that I love and cherish. My local website is served by Laravel Valet, powered by NGINX and PHP7.4.

The intention was to deploy the website on DigitalOcean, using Laravel Forge. Who better could help me deploying than the creator at Laravel? And sure enough, it worked as intended for my v2 website. That site was also hosted on DigitalOcean on hosted server harmonious-flower.

Deploying to DigitalOcean

My first plan was to publish my new website on the same server as where the v2 stays.

There I encountered glitch #1. I cannot use the same servername for both. Actually, that makes sense, doesn’t it? Sure enough with 20/20 hindsight vision. Not when your nervous in front of your computer, hoping (praying) for a smooth migration. I can assure you, encountering a glitch so soon in the process turns even the coolest guy into a paranoid android. Remember, I’m just an amateur-developer.

After 2 minutes thinking and shaking, I decided to take down my old site. After all, I was pretty condident in the new code. It also meant there was no easy way back. I went all-in.

I first uninstalled the repository of v2 and installed the repository for v3.

That didn’t work as intended and after a couple of minutes I found out why. v3 was working under PHP 7.4 whilst v2 was under PHP 7.3. So, I had to force a load of PHP 7.4.

I opened the nginx-configuration file and close to the bottom of the file changed 7.3 into 7.4.

Closing the file, I hit the restart server menu.
And this is where I started panicking!

One major drawback of Laravel Forge is that it never shows what’s happening. Is the server rebooting? Is the webserver rebooting? Is rebooting finished? How long should I wait before performing the next action.
We are left with a kazillion questions.

Being in unknown territory, I’m clueless. Reloading the nginx-configuration file doesn’t work (I kept having a spinning wheel). Sure enough, I must have done something wrong changing 7.3 into 7.4. There must have been another way to set the PHP version and now it is too late to recover.

I decided to hit the DELETE SITE-button and start from scratch.

Returning to the server page, the old site was nowhere visible and I was happy to create a new site

Tough luck! using the same levipe.be root domain, Forge warned me that the site was still existing. I was growing desperate by the minute… especially when levipe.be would return to the list of active sites with a spinning wheel next to it.

In my urge to move forwerd, it seems like I managed to break everything. Waiting another 30 minutes without doing anything resolved nothing. I had but one more choice… publish the v3-site on a new server. And so, I upgraded my Forge-plan to handle multiple sites and created another server, lingering-fog

On a fresh server…

I convinced myself this was for the better. What could go wrong if I started from a clean slate? Nothing, right?

So, I installed the website on the new server, using the same root domain as the one used on harmonious-flower. Forge managed to pull the repository from github but deploying didn’t work, returning a SQLSTATE error.

I could for the life of me figure out what went wrong until I took a deep look at the deployment script. As it turns out the standard deployment script would try to migrate the database. Working with statamic, there was nothing to migrate. Deleting the migration statements got me past the deployment stage.

Am I out of the woods? Not yet!
levipe.be is still pointing to the old server, not to the new one. I changed the A-record in my DNS. Having put DigitalOcean in charge of my DNS greatly facilitated this. I mean, this is really as hard as it gets. Just select the server to which the domain name needs to point.

At that stage, I decided to call it a night. Sure enough, it’ll take a couple of hours before the DNS-servers would link my domain to the new server’s IP.

Waking up a couple of hours later…

I typed “levipe.be” in my browser. No luck.

Were the DNS servers not updated? Pinging levipe.be got me the info I needed. Yes, the DNS servers were updated.

I had to look further but at least I knew I was progressing and the panic ebbed away. On the contrary, I was quite focused. I noticed the lock in the address bar though I didn’t install an SSL-certificate yet. How odd! I knew I had one on the other server but not on this one.

So, I decided to create and install a new one one the new server. Forge has all the tools for that… and it snapped at me. The issuer couldn’t connect to my new site.

I figured out this was an issue with the old server still playing tricks on me. With this fresh start of the day and a boost of confidence, I decided to delete the old server. Sure enough, this helped Forge to create the certificate and install it on the new server.

And there I was: my new site was showing up!

The details…

I wasn’t out of the woods yet.

A couple of functions didn’t work as expected and to start with, the product pages gave me a “500-error” on my page. How could it be? The pages work perfectly on my local machine. I soon figured out where the problem was situated.

This is the high level architecture of the website

On the right, ODOO is the ERP-system I’m working with. The data can be accessed through the xmlrpc protocol.

SSH-ing and PHP -m -ing my brand new server, I soon found out that there is no xmlrpc module installed on it. apt install to the rescue…

apt install xmlrpc

And there, presto, my site and its e-commerce functions were working. Or were they?

I still found a couple of hard-coded references to my local machine and the test-keys for stripe. I decided to recode a bit and make the code environment-neutral. Creating a “PRODUCTION” key in the .env file made it all simpler to switch between machines. Or work with a different .env in production alltogether. Forge has made this really easy!

Learning lessons

Finishing up the deployment, I learned a couple of things that I’d like to share with the amateur-developers.

• Working with a fresh head really helps. One is much more focused after a couple of hours of sleep than after a couple of hours of stress;
• Work the problem. As I progressed through the issues, I noticed they were more and more refined. This helps build confidence along the way as I was progressing at a steady pace;
• You should also know the code on which you rely, not only the code you wrote. Debugging the xmlrpc error, I got from the 500-error to a “no response” error whilst checking the connexion. It was only when I dd-ed the error in a catch-block that I found out XMLRPC-client was missing;
• Learn the basics of SSH. This is awfully important if you need to make modifications to your server as I had to;
• Make your code environment-neutral;
• Deployment software is a real help; It worked against me in the early stages of this migration but as I progressed, it greatly helpt me setting up the nginx-config file to include SSL-certificates and all the necessary rewrite rules;
• Write every step down. Or copy-paste them into your favorite tool (evernote, notes, …)
• Deploy your new site on a separate server and publish it on a different dns name so you don’t have to take down your old site until you’re 200% sure it will work as planned. Then promotion to prod is just a matter of a dns change.