I have a PHP project that I'm currently developing.

I'm nearly finished and I was wondering what is the best practice when it comes to beta testing and deploying updates/changes to the production site?

For example, in order to test out new features, I thought about creating a sub-domain called beta.mysite.com that uses a duplication of the same project files as the production version and a duplication of the mysql db.

Then after I test everything out, I need to export the mysql tables (if I changed the db structure) and copy over the files to the production area.

But how do I do all that with keeping all the data that have been produced during my beta testing?

I'm the only person that works on this project, I currently don't use any versioning tool, just Dreamweaver.


4 Answers 4


I would highly recommend implementing a VCS for yourself. Even if you are the only developer, it is a great tool to have. You will be able to deploy code easier, undo mistakes in an instant, and track the evolution of the code changes. For this, I have found Mercurial to be a great tool to use given its fast setup and overall simplicity however feel free to use any that you like (git, SVN, etc.).

As far as deploying with a VCS, you can create tags for various releases in your code base and work on multiple releases at once (beta for 2.0, dev for 3.0, etc.). Then, deploying the code from beta 2.0 becomes a matter of running a single command.

For the Database synchronization, I have found DB Deploy to be very helpful for updating my Database to the latest that the current code base requires. This is useful for updating your test environment's database to the appropriate configuration as well. Using this tool, you can make all the changes required with a single command.

  • This sounds great. I have never used any VCS systems but I really want to start now. I get the part where I develop and then 'commit' to the project 'official' release. But how is using VCS helping me when I am trying to have a 'beta' environment, and than deploying or 'committing' to production?
    – Or W
    Commented Mar 28, 2011 at 22:31

If I understand your question, it sounds like you'll need to create a script to alter the existing SQL tables in the production area, rather than simply replacing them. Check out the MySQL Alter Table Syntax. (If I've misunderstood your question, please clarify.)

Also, I think it's preferable to have your development area on a separate machine, perhaps on a local VM.

  • Correct except for the part about having a separate development machine. This increases the risk of having different configurations which might result in deployment that causes major problems.
    – Kenneth
    Commented Mar 28, 2011 at 17:34
  • @Kenneth, that's the wrong way to think about it. If you don't use a separate machine or VM, you will likely have "bleed over" from other projects, such as libraries that you have installed, that you may forget about and rely upon. When you attempt to deploy a project developed in this situation, you will run into serious issues as you try to isolate/remediate the dependency problem.
    – asthasr
    Commented Mar 28, 2011 at 17:45
  • @syrion I've always maintained a clean beta folder and written my code in such a manner that this wasn't a problem. But this is an important point.
    – Kenneth
    Commented Mar 28, 2011 at 18:16

As was already mentioned you do need to look into alteration scripts. You may make alterations to the tables on the live site manually if there aren't many changes. But following this if the data needs to be manipulated to fit the new tables then you can usually program up a quick php program that can cycle through the tables to make all the changes. (Again if the size of the data isn't large you might be able to make these changes quicker manually in some cases otherwise this is the approach I would recommend.)

Also I can speak from experience when I say that your initial idea of having a sub-domain on the same server is your best option for testing. Otherwise you risk having different configurations that really can cause MAJOR headaches at deployment time. In some development you're not able to do this always but if you can I would highly recommend it. Other than that you should be set for your deployment needs.

  • One alteration: If the development is sensitive and you don't want to risk discovery before deployment then you will need to keep it on a private server that isn't available on the web.
    – Kenneth
    Commented Mar 28, 2011 at 17:39

Have you looked into tools like PHPUnderControl, Phing, Ant, etc? They will automate a lot of the deployment work for you.

Alternatively, just build your own Bash script which builds a production-ready version of the code and rsyncs or SFTPs it to the production server. Automating is good because it prevents you from forgetting to do something when you have to update the site in future.

Immediately after putting it on the production server, run Selenium tests over the app to make sure nothing is wrong. This is where version control is great - if there is a problem, you simply run your build script over a previous version and the problem is contained.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.