Does anybody have a development/staging/deploying workflow with php/mysql?

Question

I'm thinking about a good workflow for php/mysql web-development.

Anybody got some tips?

Answer 1

Here is what we do:

1. Everyone works on their projects in their branch (code, tests, etc)
2. When everything looks good, it is merged into Trunk
3. phpUnderControl rebuilds Trunk, runs all of our phpUnit tests, builds documentation, updated db, etc
4. If all that passes, we merge into Stable
5. Stable gets fully rebuilt like Trunk
6. Stable is manually promoted to our Production server

We have a few custom scripts that take care of our database upgrades and our push to Production. For our database we keep all the deltas in a single folder and the script checks the current DB level against the available deltas and, if needed, applies them.

For promotion to Production we have another script that pulls down all the production data and then runs rsync to push up changes.

You don't mention what level of control you have over the servers, but the overall process would be the same for general development.

Answer 2

Ours is a lit simpler than dragonmantank's (we develop in the Devel branch, and when we want to make it live, we svn merge all the changes into the live branch), but I will recommend strongly treating your configuration data (data that's mostly read by the application and not created by it) as you would source code. Version your .sql files. Because your data affects your website's functionality just as much as the source code does.

Answer 3

Check out Phing.

Answer 4

I think everybody does theese things slightly different, depending on the exact application. Here's our setup:

Before a release:

• Everybody commits to /trunk.
• When we want to roll a release, we copy the trunk to /tags/yymmddhhiiss.
• We stabilise the tag.

Once it's stabilised, we run the deploy script:

• On the production server, checkout the new tag.
• Take a dump of the database.
• Stop daemons and shut down the web application(s).
• Switch the symlink /current to point to the freshly checked out tag.
• Run migration scripts.
• Restart daemons and applications.

If we need to push a small change out quickly, we merge it to the current tag, and we can then run a much simpler hotfix process at the server:

• Stop daemons and shut down the web application(s).
• Run svn update
• Restart daemons and applications.

Note that there are certain tools that are aimed at structuring/automating theese processes. Phing is one, and Symfony has its own batch system, which used to be a stand alone project called pake. And as if that's not enough, Zend Framework are about to create their own variant. It's all really a bit of a mess, but Phing is probably the most widely used. You can also use something non-php specific, such as Ant or Capistrano. We just use shell scripts, which basically fills the same need.

We also have a continuous build running, which checks out from the trunk and runs all tests. Currently we just have a basic collection of shell scripts doing it, but we're considering to switch to PhpUnderControl or xinc.

The migrations step perhaps deserves a bit explanation. Theese contains changes to the database, as well as other tasks that must be run for the new release. Our migrations are a bit simple at the moment; We simply have a folder with a bunch of .php and .sql scripts and the during the migration, theese are run in sequence. The way we keep track of which changes has been run, is by emptying the migrations folder right after a new tag has been made. It would probably be smarter to use the database to log which changes have been run though. We are considered adopting something like ruckusing for this purpose.