Every developer has their own way of going about their coding so I thought I would share mine, for those who may be curious.
#1) I create a local development environment.
I personally use DesktopServer (this is an affiliate link but a genuine recommendation!) to quickly get local environments up & running and it saves me start up time by using their super handy “blueprint” capabilities. Essentially, this allows me to create an initial starting point that has the few standard plugins I use (Advanced Custom Fields Pro, Gravity Forms, Yoast SEO, WP Migrate DB Pro) plus my starter theme, which is kind of a re-organized version of Joints with some other modifications. With blueprints, I don’t have to waste my time installing the same plugins repeatedly or always dropping in my starter theme so I can get moving much quicker. If you don’t like DesktopServer, plenty of alternatives there but in terms of the most simplistic way to dive into local development, I’d recommend it!
WP Migrate DB Pro (this is an affiliate link but a genuine recommendation!) is one of the plugins in my blueprint and also highly recommended. It allows me to push & pull databases as needed so I’m frequently using it in my dev process.
#2) Create a repository for the theme.
Version control is your friend, kids. As someone who is usually a solo dev on projects, it took me longer to see the benefits of version control than I’m proud of. If you’re considering whether you should be using Git for your projects, just do it. If you aren’t comfortable in the command line or just prefer a GUI, I’d recommend SourceTree. I personally just put the theme under version control and then make a separate repository if I do any custom plugins for the project. Some people choose to version control the entire wp-content folder or everything in WordPress. There are plenty of opinions out there about what should be done but my approach is mostly theme only.
#3) I create a public staging environment.
This may exist on my own server or this may exist on a client’s server or dedicated staging area. While this isn’t necessary to start development, it is necessary to share progress as a client can’t see my local environment unless I do something like a screenshare, which would be overly time-consuming during the development process. I’d rather a publicly accessible URL that can be accessed and experienced at the client’s convenience so a public staging environment is required there.
#4) Configure DeployBot
I personally use a service called DeployBot to push from local > staging or local > production. When starting a project, I’m frequently configuring DeployBot to do automatic pushes from my repository to the staging environment. From configuration onward, I’m just coding and then when I make a commit, it pushes them to the staging server and I don’t have to manually do anything there (I rarely touch anything like sFTP). DeployBot also allows manual control of deployments, which is recommended for production environments.