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.