Production Deploys

This was an exciting week for me. It was New Year's Eve, and I felt like working on Scribelate, but I didn’t feel like diving into a lot of code work. I had already done much of the coding to get a fairly functional version running locally. Plus, I’d registered the domain scribelate.com a while ago. So, I thought it would be a great idea to try setting up a production environment on New Year’s Eve.

It ended up taking most of the day and into the evening. I got pretty close but didn’t quite have a fully working version by the end of the night.

When you think about all the different things that go into a production build, it’s a lot. Setting up server environments, deploying the production build version of the code, configuring a database, deploying the database model… there are so many moving parts.

The biggest challenge I faced—and as I told my wife, "Ignorance is a terrible thing"—was with my backend services, which are written in Go. Typically, building a Go application is straightforward. The command is:

go build -o appname

This worked well until I tried deploying the Docker image into the production environment. This is where the ignorance kicked in... I do my development on a Mac M2 and had convinced myself the problem was related to the M2. I ended up giving up on New Year's Eve and started trying to fix it first thing in the morning by using an old Linux laptop I had for just such a problem.  Alas, I had been wrong and needed to dig a little deeper.  What I needed was a better build command build command that would build an executable that wasn't dependent on existing libraries.  Something more like this:

CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o appname

Once I ran that command, everything worked fine.

So yeah, I wouldn’t say that New Year’s Day was the official launch day for Scribelate, but it was a pretty big milestone on that path.

I hope your New Year’s Eve was as fun as mine was.

– Aaron