Setting up a PHP web project, the infrastructure

Question

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

Answer 1

I noticed this wasn't getting much exposure. It's also something I'm interested in. Are you aware of Phing? Have you tried it?

Andrew

Answer 2

Here's a good guide on automating deployment of PHP applications with Capistrano.

Answer 3

@andrew : I've tried Phing and ended up with phpUnderControl. The problem with Phing is that to manage code coverage, it has to actually include all the files in you project, which for our project just does not do it. The approach of CruiseControl worked better for us. Give them a try, they are both easy to setup - the hard work is to build the tests....

Answer 4

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 Doctrine 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.

Deployment

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"
end

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.

CI

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..

Answer 5

For database changes, we have a directory in the VCS:

+ dbchanges
|_ 01_database
|_ 02_table
|_ 03_data
|_ 04_constraints
|_ 05_functions
|_ 06_triggers
|_ 07_indexes

When you make a change to the database you put the .sql file into the correct directory, and run the integration script that goes through these directories in order, and import every change into the db.

The sql files have to have to start with a comment, which is displayed to the user when the integration scripts imports the change, describing what it does. It logs every imported sql file's name to a file, so when you run the script next time, it won't apply the same change again.

This way, all the developers can simply run the script to get the db up to date.