How might I improve my development and deployment strategy?

Question

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:

My local machine AKA my development environment
A staging account on my dedicated server so that I can test the web app
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.

Olivier: I've edited your question in an attempt to make it more specific. SO isn't a forum, and tends to work poorly for "any comments on this?" questions; I think you did a good job of identifying specific problems in your final paragraph, and so have attempted to emphasize those (also altering the focus of the title away from a solicitation for anecdotes) — Shog9
can anyone plz tell me whats the general convention and meaning associated with dev, stg and prod. It seems that I am confused about their meaning (or it seems I have been using the convention/semantics which are not in sync with what others are using). Thanks — Mahesh Velaga
I believe this is the usual convention: Dev: environment for developers Staging: environment for quality assurance (before pushing changes to prod) Production: public environment — Olivier Lalonde

Darrell Brogdon Darrell Brogdon · Accepted Answer · 2010-01-02T19:35:31

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.

How might I improve my development and deployment strategy?

2 Answers