Question

The project I am working on were are trying to come up with a solution for having the database and code be agile and be able to be built and deployed together.

Since the application is a combination of code plus the database schema, and database code tables, you can not truly have a full build of the application unless you have a database that is versioned along with the code.

We have not yet been able to come up with a good agile method of doing the database development along with the code in an agile/scrum environment.

Here are some of my requirements:

1. I want to be able to have a svn revision # that corresponds to a complete build of the system.
2. I do not want to check in binary files into source control for the database.
3. Developers need to be able to commit code to the continuous integration server and build the entire system and database together.
4. Must be able to automate deployment to different environments without doing a rebuild other than the original build on the build server.

(Update) I’ll add some more info here to explain a bit further.

No OR/M tool, since its a legacy project with a huge amount of code. I have read the agile database design information, and that process in isolation seems to work, but I am talking about combining it with active code development.

Here are two scenario’s

1. Developer checks in a code change, that requires a database change. The developer should be able to check in a database change at the same time, so that the automated build doesn’t fail.

2. Developer checks in a DB change, that should break code. The automated build needs to run and fail.

The biggest problem is, how do these things synch up. There is no such thing as ‘checking in a database change’. Right now the application of the DB changes is a manual process someone has to do, while code change are constantly being made. They need to be made together and checked together, the build system needs to be able to build the entire system.

(Update 2) One more add here:

You can’t bring down production, you must patch it. Its not acceptable to rebuild the entire production database.

Answer 1

You need a build process that constructs the database schema and adds any necessary bootstrapping data. If you’re using an O/R tool that supports schema generation, most of that work is done for you. Whatever is not tool-generated, keep in scripts.

For continuous integration, ideally a ‘build’ should include a complete rebuild of the database and a reload of static testing data.

I just saw that you have no ORM tool… here’s what we had at a company I used to work for

db/ db/Makefile (run `make` to rebuild db from scratch, `make clean` to close db) db/01_type.sql db/02_table.sql db/03_function.sql db/04_view.sql db/05_index.sql db/06_data.sql 

Arrange however necessary… each of those *.sql scripts would be run in order to generate the structure. Developers each had local copies of the DB, and any DB change was just another code change, nothing special.

If you’re working on a project that already has a build process (Java, C, C++), this is second nature. If you’re using scripts in such a way that there is no build process at all, this’ll be a bit of extra work.