Applying Agile SCM to Databases

that must exist before the application accesses the database.

With the correct version of these artifacts, and with the appropriate scripting in place, any developer should be able to recreate the version of the database that goes with a version of the codebase. Also, these artifacts serve as a starting point for answering questions about what changed between releases.

At first glance, versioning only artifacts such as DDL files seems too simplistic to solve any real problems. Yet it is an essential first step. It is also an important step in moving your database in line with your agile code development process.

Being Agile

At first glance, databases are very different entities than source code, so you may feel that your standard toolbox of tools and patterns for managing changes to source code may not be up to the task of managing versions of your database components. Consider, however, that your goals for managing your database are very similar to your goals for managing your codebase. Also, consider that your database and your code depend on each other, so there are many benefits to using a similar approach. If there are too many differences, and the database changes happen with a different pulse, your database will be a bottleneck. To be agile, you need to help things work smoothly.

In an agile environment, developers can always recreate the latest version of the application from what is in the version management system, and they can test changes to their code before committing it to the codeline. These things should also be true of databases. 

Others have described approaches to using databases in an agile environment. Scott Ambler's site: http://www.agiledata.org/  has a number of useful articles and links about data modeling in an agile environment. Scott's book, Agile Database Techniques is a useful reference. The article Evolutionary Database Design by Martin Fowler and Pramod Sadalage ( http://www.martinfowler.com/articles/evodb.html ) provides a good overview of how to work with databases in an agile environment. This article will focus on the version management tasks.

The patterns from the Agile SCM pattern language are relevant to the database domain as well as to the code domain. The implementation has additional complications, since a database is more involved than source code, and we don't have the tool support that we are used to for source code.

Consider how the following patterns apply to Agile Databases:

• □ Active Development Line : The database is part of the application, and changes to the database should not be a bottleneck. You need to be able to make changes to a schema, and make the changes available to other developers.
• □ Private Workspace : being able to experiment with a change before releasing it to the rest of the team is an essential mechanism for encouraging change, while also providing for stability. You need to be able to create your own database that you can alter, test with, etc without interfering with the work of others. To do this, you should move towards having each member of your team having their own database that they can experiment with changes to the schema, and recreate the tables at will.
• □ Private System Build : you need to build and test your application with your version of the database. Being able to create a version of the application, including any database components.
• □ Smoke Test, Unit Test, Regression Test : you need to test both the application with the new schema, and any issues relating to the new schema.
• □ Release Line : There may well be a production schema and a