Build Process and DB sync

Josh Tenenbaum — Mon, 27 Feb 2006 04:24:00 GMT

I've embraced CruiseControl.Net creating six build processes for our application.

A development build that runs 15 minutes after a commit
A test build that runs on demand.
A maint branch build that runs every 15 minutes.
A maint branch test build that runs on demand.
A rebuild of the test database that runs on demand.
A rebuild of the maint database that runs on demand.

I've run through about 4 iterations setting up the process. In two years, we finally came up with a stable process that with one exception hasn't messed up. We've probably deployed about 100 - 150 times in those two years (that includes deployments to the client's staging/testing environment).

The hardest part has been our database. We copy down a copy of the latest version of our production database (its only about 1GB) everyday and archive that. But, if the deployment is done after the backup, it was causing chaos for a reproducable testing environment. We wanted to create the closest match we could to the production environment. Especially since most of our bugs deal with strange cases, we also need to have an enviroment to reproduce without touching the client's data.

In order to explain my database process, I need to explain how we number our builds. Each build, increments the revision one. So, if I commit a file, the automated build will update the build number from 3.4.0.3 to 3.4.0.4. When we deploy, I update a shared assembly info file and change it to in this case 3.4.1.0. The next build will then increment up. Our database patches are also named in this way, so we could have patch_3_4_0_0.sql and patch_3_4_0_1.sql. The deployment package (a zip file) could find these fine, but in interim states where, the build was incremented, but the latest database backup had not been updated problems arose, a manual process--prone to error--resulted in lots of headaches.

My thought was to write an NAnt task to do this. It was actually amazing easy. I went for the easiest path, rather than efficient.

go through and find every patch in the path passed in
for each patch found, go through the db and see if it had been run*
copy the patches to the dest location parameter.

* As part of our patch, we write the patch version, date and time to a table in the database.

Its not my best work, not my worst. Suggestions welcome. If you want to look, here is the source, feel free to use it.

Automated Build (CC.Net)

Build Process and DB sync