Continuous Deployment
Automating tasks has been a key focus for me the past year, resulting in learning how to write PHPUnit tests, figuring out how to setup the test suite for WordPress plugins, and today… continuous deployment!
An article by Steffen Bewersdorff on CSS-Tricks was instrumental (seriously, likely wouldn’t have happened otherwise) in helping get continuous deployment setup for this site, and hopefully more.
What is continuous deployment?
Continuous deployment allows for build and deployment processes to be automated, so every time a change is made and the trigger to deploy occurs, those processes run and perform the deployment in the background, without any human intervention. This is a big time saver, and removes an opportunity for human error.
First setup
I don’t use package managers or have any build processes (I’ve yet to see or be shown any value), so it’s just a deployment process for me, which while technical, should be pretty easy for a true developer to handle (especially if following along with Steffen’s article).
My development process follows Steffen’s directions nearly identically (without the build step): SSH in GitHub Actions to send the files over to Hostgator (even on a shared server!). Now, whenever I make a change (theme style, new plugin, or core/plugin update), I need only commit the change to the production branch, and GitHub Actions does the rest.
A small warning
As you automate more and more things, don’t forget to actually go to the site and check it out. Automations typically will alert you if something goes wrong, but it is possible for the automation to succeed, and you’ve introduced something that breaks the site in a different environment.
Update: This site is now hosted on Netlify Starter, with WordPress hosted locally using Local, static file generation via the Static HTML Output plugin, and deployment performed by Netlify’s integration with GitHub.