As I’ve started to dig into Statamic one of the first things I want to tackle is having a solid workflow and deployment strategy and unfortunately I’m finding a bunch of dead links to posts from developers from 2015 that haven’t kept their domains up[1]. While the the forum has a bunch of answers I’m not sure that I have one I love yet.

This serves to document what I’m doing right now as I build my first Statamic site hosted on a Digital Ocean server where I develop on the server because that’s how I do development. I’ll deploy to the actual “live” site later.

To start I used the Statamic via Forge based of their instructions. One gotcha I had out of the gate is that Forge creates your first user not as root like Digital Ocean does, but as forge. Make sure that if you’re trying to log into your new server you use root@your.ip.address.

The second gotcha with the Forge deploy was that I needed to use Forge to add my SSH key to my site. You can do this easily, but it wasn’t clear to me out of the gate.

With those two things out of the way, how does one manage their development environment and production environments? Particularly in the future when I’ll have clients changing content on the live site that we’ll need to integrate into staging environments?

Enter Spock

At this point Spock seems like the best option to use to version control content and maintain development because elaborate Git workflows seem like a recipe for disaster. To get Spock working with my remote development workflow, I’ll need to spin up another server with Statamic on it (or another site on this domain) and use that as my remote development environment. Then, when I deploy with Git Forge will push my changes to the “staging” site that a client would look at.

At least that’s the way it works in my head since I don’t do local development anymore, because you know I work on an iPad most of the time.

Incidently Spock is also the top recommended way by Statamic in it’s docs.