In this session, we discuss my typical work flow in managing a Live Site and Development Site.
Managing a Live Site and its Development Clone Workflow
Managing a Live Site and and its Development Clone is my typical workflow. Somebody else might have a different way of doing this but this is the way I’ve found to be useful and this is the way I work on client sites and a variation on how I work on my own site. I actually work on my own site locally because I’m doing programming and I like that to have a bit tighter access to the entire body of the code on the site in NetBeans and so it’s a little bit different for BYOB Website. But I do it this way for everything else I work on.
What you do is you have this starting point where your live site is in a place and your subdomain or your development site is in place and they are essentially equal, this one is an exact replica of this one. It’s important to understand that in most instances of WordPress sites. This condition only exists for a relatively short period of time because as soon as you have any change to the live site, the development site is no longer an exact copy of it.
BYOB website changes probably a hundred times a day and it changes with comments that are posted with posts on the form, with videos that we add to the site, with transcriptions that we add to the site, with sales that are made on the site and with members that join the site. We just have this whole range of changes that happen to the site constantly throughout the day. The time in which the live site and the development site are identical is very short and this is a typical case where they are not the same.
Minor File Change Workflow
You have a couple of different types of workflows to consider. One of them is just the Minor File Change Workflow. Maybe you’re making a few changes to Custom CSS or you’re making a few changes to the Custom Functions PHP file. Those changes don’t change anything in the database, they don’t affect plugins because they aren’t affected by those files.
It doesn’t result in new pages or posts, it doesn’t result in additions to the media library and doesn’t result in new comments. Plugins, pages and posts, media library, comments are sets of data that are stored inside the database, so a minor change does not include making those kinds of changes.
The workflow for minor file change is that you sit down here and you work on NetBeans and you tweak Custom CSS and Custom Functions PHP in NetBeans. Make a little tweak, upload and check it until you’ve accomplished what is it you want to accomplish in this minor change. Once you’ve done that, you take those change customization files and you simply FTP them back over your live site, it’s as simple as that.
Using BackupBuddy to Clone a Site
This is a very simple system to work; however, what most people are dealing with when they ask this questions is they want to make a major change to their site and the major change is the one that is more complicated. The way I do it is by using BackupBuddy to make a snapshot of the live site then I clone that live site to a development site. If I had to do on a site that’s already there, I would just delete the database, take the new clone and use ImportBuddy and BackupBuddy to essentially clone the live site on that development server.
That is the easy way of how I do it, I never do it the hard way myself. Once you’ve made this cloning of the live site, the result of Step 1 is that you are at the state of equilibrium where the development site and the live site are identical. On a major change, what you’re going to do is potentially upload images, add plugins and make changes to the development site.
You may in fact, make changes to the Customization Files and upload those via FTP and the live site is just floating over here doing its thing and being modified in a way it’s being modified while the subdomain site, the development, is not being modified the way this one is. It’s not getting any of the new comments, it’s not getting any new blog posts or forum posts or any of the new things that happen on the live site. It is insulated from those kinds of changes but it’s getting all of the changes that you directed toward it if you installed plugin, if you upload a file, if you make a change in the customization file.
Approach to a Constantly Changing Site
You really have two different ways to approach this. The first way is the way I always have to approach it if your site is constantly changing. Once you’ve tested what you want to look like in your subdomain development site, you simply have to redo those same edits and changes on your live site. If you added some plugins and create a plugin settings, you have to add the plugins to the live site and change the plugin settings. If you’ve added images to your media library in order to accomplish something, you have to add those same images to the live site’s media library.
Then you use FileZilla to upload any change to Customization Files. This is the workflow that I have to follow because there’s never a point at which my live site can be replaced by another site. I can’t take a development site take a snapshot of it and replace my live site with that development site because I will always have missed some data. I have to not essentially double my work, but I have to repeat work that I’ve done on the subdomain development site on my live site as well so I’m doing some of the same work two times.
When you’re finished with that, your development site and your live site still aren’t the same. The live site got the benefit of all the changes that you made to the development site but the development site did not get the benefit of all the changes that happen otherwise to the live site so you still don’t have two sites that are identical. The condition in which they are identical is only at the very beginning and only for a brief period of time.
Approach to a Site that doesn’t Change Very Often or doesn’t Change at All
However, if you have a site that doesn’t change very often or maybe doesn’t change at all, it don’t take comments, you haven’t posted any blog posts, there’s no membership component and you’re not selling any products, the live site only changes when you physically make a change. You can in fact, follow this procedure which is then reversing that cloning process and making a cloned copy of your development site and deleting the live site and replacing it with a clone of your development site.
This is very quick and easy with BackupBuddy. If I’m working on a site that has very little change on it or doesn’t have any change on it at all, then I’ll use this condition. When that happens, both sides doing that being the same because what you’ve done is you’ve entirely replaced the live site with the development site.
You have those two sets of conditions. I did the live site changes or the live site doesn’t. If the live site changes, then you have to manually repeat the work that you did on the development site on the live site. If the live site doesn’t change, then you can simply clone the development site and replace the live site with the clone and you only had to do that development work once.
That is the workflow that I go through on my own site and on clients’ sites. That sort of a launching upfront for us to talk about the development of this subdomain’s development site.