I am currently pushing static file changes like this:
git > remote repo > deployHQ > production
Seems to work great for static files.
Finding a similar solution for the database hasn't been as fruitful, but its not the end of the world. I can always download a fresh database dump and import locally to work on a change, and then re-upload the dev database once everything is complete.
The problem I envision here is that any changes (new posts or pages) that take place during that time will be deleted when the dev database is re-uploaded. (I could be wrong here, as database management is not my strong suit.)
Basically, I am trying to find a solution to two problems:
1. Prevent redundant work
Lets say I add a contact page, /contact-us. I can do that locally, edit css files as necessary, and then upload all the static files that were involved. But then I have to go onto the live server and add the page again, copy over the html, etc. Basically doing the job twice.
The good part about this route is any posts/pages/comments that went live during the creation process are unaffected.
2. Prevent recent database changes from being overwritten
If I download the current database and start working on the new contact page locally, I can upload the static files along with the local database once everything is complete. That should produce the same result without having to manually create the page on the production server again.
The problem here is if anything happens to the production server's database during that time frame. If it took two days before it was complete, any new posts, comments, etc would be overwritten when the dev database is moved back to production. (I think)
Is this an elegant solution to this or a best practice? If not, how do you manage it?