How can I best set up my PHP (LAMP) development environment so that I have development, staging and production servers. One-"click" deployment to any of those, as well as one-click rollback to any revision. Rollback should also rollback the database schema and data to how it was when that source code was current.

Right now I've done all of this (except the DB rollback ability) for one application using shell scripts. I'm curious to know how others' environments are setup, and also if there are any generic tools or best-practices out there to follow as far as layout is concerned.

So, how do you do this? What existing tools do you make use of?


UPDATE: Just to clarify as there is some confusion about what I'm interested in.

I really want people to chime in with how their environment is set up.

If you run a PHP project and you have your DB schema in version control, how do you do it? What tools do you use? Are they in-house or can we all find them on the web somewhere?

If you run a PHP project and you do automated testing on commit (and/or nightly), how do you do it? What source versioning system do you use? Do you use SVN and run your tests in post-commit hooks?

If you run a PHP project with multiple dev servers, a staging server and production server(s), how do you organize them and how do you deploy?

What I hope to get out of this is a good idea of how others glue everything together.


Your question is mis-leading. CI describes more a QA thing. E.g. unit testing, checking code coverage, building documentation, checking coding style, PMS, etc.. Are you really looking for advice on deployment?

Written by Till

I removed continuous-integration, because that's not what you are asking for.

Written by Till

Accepted Answer

Our production environment includes the following:

  • 3 frontends who serve our website
  • 2 database backends (Master-Slave, replication)
  • 1 mixed which runs httpd and database for adserving

Our development environment is a single server running both database and httpd, configuration-wise we have different workspaces for everyone setup and our VC is subversion. Staging is rather simple too - it runs on one of the frontends.

Database changes

Initially we spent a lot of time on the database design and it seems to have really paid off. We haven't changed anything major in five months now. Most of the changes we deploy are on the frontend. Now, so far we run all the changes to the database manually and I always wrote a small script to revert.

If I had more of those, I'd use phpDoctrine and Migrations here. I've never actually had the chance to use them in production but I've played with those extensively already and they seem very powerful.


So whenever we deploy a new version we create a tag of the code which we check out on staging, then go through a couple lists of checks etc. and then we deploy the code on the production frontends. For doing all of the deployment, I have a couple tasks setup in Capistrano.

Check out this sample capfile:

role :www, "web01", "web02", "web03"
role :web, "web01", "web02", "web03", "web04"
role :db, "db01", "db02"

desc "Deploy sites"
task :deploy, :roles => :www do
    run "cd /usr/www/website && sudo svn --username=deploy --password=foo update"

Capistrano also allows you to run any other command without defining a task:

cap invoke COMMAND="uptime" ROLES=web

(Requires the role "web" to be setup. See example above.)

Coding style and documentation

We pretty much adhere to the PEAR Coding standard, which we check using PHP_CodeSniffer (phpcs). When I say pretty much, I mean that I forked the sniffs provided and added a few exceptions of my own gusto.

On top of coding style, phpcs checks on inline documentation as well. This documentation is created by phpDocumentor in the end.


I have both of those tools setup in our CI-server (continuos-integration), which is phpUnderControl using the above and CruiseControl, phpUnit, Xdebug (a couple code metrics...), etc..

unit-testing is something we currently lack. But what we do right now is that with each bug we find in our parsing engine (we parse text into certain formats), we write a test to make sure it doesn't come back. I've also written some basic tests to check the URL-routing and the internal XMLRPC API but this is really subject to improvement. We employ both phpUnit-style tests and phpt as well.

The CI-server builds a new version a couple times per day, generates graphs, docs and all kinds of reports.

On top of all of the tools mentioned, we also use Google Apps (primarily for email) and keep a Google Sites wiki with all other documentation. For example, deployment procedure, QA test lists, etc..

Written by Till
This page was build to provide you fast access to the question and the direct accepted answer.
The content is written by members of the community.
It is licensed under cc-wiki