Staging database good practices
I'm about to deploy to production a fairly complex site and for the first time need a staging environment where I can test things in a more realistic environment, especially with regard to some external services that cannot be run locally.
My general plan is to develop & test first locally, push simple changes (small bug fixes, HTML/CSS, JS, etc) direct to production, and for larger changes, push first to staging subdomain for thorough testing and then to production.
I don't think that I need to keep the staging and production databases in sync (occasional manual updating would do) but I'm wondering if there are any general good practices with regard to maintaing a staging environment in relation to a production environment, especially when it comes to databases.
Any general thoughts/advice/experience would be appreciated.
UPDATE:
Thanks for the comments, I get the gist. I guess it's worth taking some time to think about this. Accepted the popular answer.
Answer
By bypassing staging and making changes in production is a recipe for disaster and disuse. As you make those changes the definition of minor begins to change. Secondly as the two environments depart (i.e. staging no longer matches production) things break and you lose confidence in the staging environment. To get the most from a staging server you should be doing automated deployments to it, fully testing and only then deploy (automated) to production (no matter how small the change). You should also make sure the complete environment are as similar as possible, and stay that way. This obviously includes the DB. I normally setup a sync either daily or hourly (depending on how often I am building the site or app) to maintain the DB, and will often run this as part of the build process.