views:

460

answers:

2

I would like to get a general consensus for the minimal/boilerplate professional PHP team development environment. I can not find this information anywhere on the web. In the open-source world there are so many choices and so many ways to do things but I've yet to find any common best-practice for the infrastructure/plumbing side of things.

Consider a small shop with a team of 5-10 developers/designers, doing LAMP CRUD apps. They need to manage development, staging and production builds. They want quality software and they can't be stepping on each others toes trying to get things done. Deployment needs to be easy and fast. Sometimes there will be hotfixes. Rolling back production server to a previous version needs to be just as fast.

Things to consider are:

  • Source code management (SVN, git, Hg)

  • Database schema/data continuous integration, tied to Source-code revision. This is one I'm particularly interested in.

  • Individual development environments (e.g. each developer has a VMware instance of the development environment to tinker with (DB server, web server, code, data, etc))

  • Managing central development, staging and production builds

  • Production deployment (e.g. tar balls, .rpm/.deb)

  • Automated testing (e.g. SVN commit hooks, nightly cron tests for slower tests)

  • Team communication (bug tracking, internal documentation, irc/im, etc)

I've left this open to edit by the community so feel free to edit/add. Ideally someone can visit this page and a few hours later have the foundations in place for their team to start developing.

+1  A: 

I'll start. feel free to edit and improve this

This is for a ficticious product called: dundermifflin.com

  1. Setup a development virtual machine running the same software you plan on using in production: e.g. Ubuntu with PostgreSQL, Apache and PHP5.

  2. Each developer runs their own copy of this VM with the hostname set to their username, (e.g. phpguy.dundermifflin.com)

  3. Setup a central staging server (same as the development VM). This is staging.dundermifflin.com.

  4. Setup a central Subversion server with a new repository for dundermifflin.com. This is devel.dundermifflin.com.

    • 4a. Add post-commit hook to run tests for "trunk" commits
    • 4b. Add post-commit hook to package/deploy to staging server for commits tagged "staging"
    • 4c. Add post-commit hook to package/deploy to production server for commits tagged "release"

This method does not address database continuous integration which means rolling back SVN to a previous revision will break the build unless your database is very static. Suggestions?

  1. Use Bugzilla on the central Subversion server (devel.dundermifflin.com) for bug tracking.

  2. Write a shell script to run PHPUnit/SimpleTest tests (to be called by item 4a).

Why bother with a separate VM per developer? I've always gone for the approach of a separate vhost, but a shared webserver/database. If you go the VM route it gets very complicated if you want to add stuff like master/slave dbs to your dev environment.
J.D. Fitz.Gerald
Everyone needs separate DBs anyway if the database changes with any frequency. Otherwise when programmer A updated the database schema everyone else's code could suddenly fail and not know why.
acrosman
A: 

For continuous integration, linked with your version control system, and automated unit testing I find this article very interesting:

Continuous builds with CruiseControl, Ant and PHPUnit

CMS