For client sites, do you have a deployment tool, or any process?
Hi @ryan_at_amezmo, and welcome!
My preferred approach for deploying sites (and development in general) makes heavy use of
git and other command-line tools.
I always store the entire site in a
git repository. For some sites (not business-critical) this is enough and I just develop directly on the live site.
git handles backups of the code, and I also take frequent backups of the database using
For sites where it’s important not to have any downtime, I host a dev/staging site on the same server as the production site. I have a couple of scripts to move things between these two environments, one basically “refreshes” the staging version to use the latest database from production, and the other one deploys any changes in staging to production.
Here are the steps my deploy script follows:
- Make sure there are no uncommitted changes in staging or production
- Push the code to GitHub as a backup (if applicable)
git merge --ff-onlyon the production site to pull the new code from the staging environment.
The “refresh” script blows away the staging site and recreates it based on the latest production database and code. Under this model, code changes start in staging and then move to production when they are finished, and content changes are made by the client in production and then migrated back to staging.
Configuration changes of any complexity are usually tested in staging first and then repeated in production. If they are fairly easy then I do that manually, or sometimes I write a one-off script, for example if a bunch of posts need to be edited in some specific way all at once.
The same kind of setup would work with a local development site also, but I’ve found that having both environments on the same server makes it a bit easier to streamline the process of moving changes back and forth, allows clients to preview and evaluate changes before they go live, etc.