How might I improve my development and deployment strategy?

I am working on a web application that runs on the LAMP stack (Linux Apache Mysql PHP) and would like recommendations on improving my workflow.

I have 3 environments:

1. My local machine AKA my development environment
2. A staging account on my dedicated server so that I can test the web app
3. A production account on my dedicated server

I do all the development on my local computer and use a subversion server which is located on my dedicated server. I set up a hook script so that whenever I commit, my "staging" account is updated with the new code.

Once in a while I make sure that everything works fine on the staging account and push the changes to my production account via a small script.

This works well enough for the most part, but there are a couple of irritations:

• My domain name is hard-coded in a couple of places, making it time-consuming to switch between environments. I can modify my hosts file manually but it's not exactly fast and it doesn't work for the 2 accounts (prod/staging) on the same server.

• I've no way of keeping the database up-to-date across all three environments. I could use the same database for all environments but I would have to take the risk of breaking the production environment.

So, my question is: what could I do to mitigate these 开发者_开发知识库problems?

UPDATE: The hard coded domain issue is introduced by a 3rd party software and therefore, "not hard coding it" is not an option at the moment.

---

Ideally you would want staging to be an exact replica of production. That way, what you see in staging you can be reasonably confident that you will see in production. Auto pushing to staging when you commit won't do this as any bugs you introduce with a commit are instantly sent to staging.

What you may want is to set up another environment and call it testing. This would be where you auto push to on commit. Use that environment to do QA and from there you can package up the code and push push that to staging for final testing. If all goes well on staging then push the package to production.

As to the domain name issue, I would recommend not hard-coding them if you can get away with it. Or at least use sub-domains for the different environments to make it easier to determine programmatically what environment you're in.

To keep your database up to date across environments you might want to consider doing a dump from production periodically and updating your staging, test, and dev environments with that dump. Once a day should work. That way you're developing and testing against what your users are seeing in production.

---

Regarding your last couple of points, the obvious solution seems to be (1) don't hardcode the domain anywhere, or if you must, at least split it off into one "local settings" file that isn't updated via SVN; (2) write a script to sync the databases (i.e. copy the production data to staging and/or your local environment, certainly not the other way around) and run it occasionally.