How do you implement the "one step build" for a LAMP project?

Question

Having the "one push build" to take your changes from development environment to live server is one thing that is very nice to have and often advocated.

I came on board with a small team running in a LAMP stack and use SVN for version control, currently deployed on a single production server (another server for development and soon to be a separate mysql server). I'm just now putting in place a lot of the organizational things that have been missing prior to me coming on board.

I am curious to see

1. how people are doing this (one step build) currently
2. see how i can implement it best for my situation (small team, LAMP environment with SVN)

Some particular challenges I'm interested in would be handling database changes (schema) and also if and what kind of "packages" are people using to keep things organized (e.g. RPMs, PEAR, etc.).

Answer 1

We used ant with Hudson. Worked like a charm.

Hudson would work with other build systems too, and not just java projects. It lets you setup multiple build targets, and will run them automatically, or manually. It also forces you to implement a way to run your build from a single command.

It doesn't solve the communication problems where the server will be unavailable during the time it takes to run the build for the deployed server.

For our schema updates and changes, we setup our ant script to do two things:

1. Update run the schema only if there's a difference in SVN.
2. Check in a schema dump after the schema changes were built.
3. If there was no update to the schema, simply use the dump to load a database

It did take a few tries to get right, but suddenly we had solved the issue of multiple developers being on different schemas. It was so easy to import the dump to update your development schema, that you could do it daily.

Answer 2

We do. We use a product called Anthill Pro to do all of our builds and deployments. It has a workflow process which set up to check out the files, do the builds, run the unit tests and then deploy the code to the servers. You can use it to deploy just about anything as the process can run command line programs etc.

Answer 3

I don't think there's a simple cookbook answer for this, because this depends very much on your environment. Whatever you come up with, I highly recommend a script-based approach, with the deployment scripts being in source control themselves. Those scripts will also allow better integration with build solutions (see below).

The simplest such script to run in your production environment would simply be the command to get latest (or get a specific version) from source control.

The next challenge is database deployment. The solution that I have come to like the most for small to medium-sized projects is to maintain a schema version table in each database and have all DDL and data update scripts in source control (including the data sources they use in compressed archives). The scripts are numbered consecutively (starting 000001 ..., 000002 ..., etc.) and the deployment script I run simply first backs up the existing database, then gets the last run database script from the schema version table, and then runs any new database scripts found in source control in correct order, updating the schema version table accordingly.

This approach allows me to rebuild database from scratch pretty quickly.

The two approaches taken together make it possible to quickly deploy your code base to several different staging machines, your QA environment, beta, etc.

---

For just a little bit more complex scenarios, you should run a continues integration build server, like Kieveli et. al. suggested, which essentially "rebuilds" your entire deployment regularly and therefore contains scripts to do exactly what you would run "manually" above.

Database deployment can also be made more sophisticated by creating a rollback script for each database script. You should then write a little controller app to handle those. There are several OSS solutions for this kind of stuff and one of them may fit your needs.

BUT, make sure you never auto-deploy your database to a production environment ;-)