Evolve an existing database schema a small bit at a time to improve the quality of its design without changing its semantics.

For years the norm for object developers was to work in an evolutionary (iterative and incremental) manner but for database developers to work in a more serial manner. The predominance of evolutionary development methodologies such as Extreme Programming (XP), Feature Driven Development (FDD) make it clear that the two groups need to work in the same manner to be productive as a team.

Pramod will present material from the 2007 Jolt Productivity Award winning book "Refactoring Databases : Evolutionary Database Design" on how to go about doing evolutionary database development, how to apply all the agile practices to database development and will talk about the following techniques:

Database refactoring: Evolve an existing database schema a small bit at a time to improve the quality of its design without changing its semantics.

Continous Integtration: Why not test you database creation and migration scripts as part of Continous Integration and apply the same rigor to the database artifacts that you apply to the application code. You should fail the build when the developer/dba makes a mistake doing a database change

Evolutionary data modeling: Model the data aspects of a system iteratively and incrementally, just like all other aspects of a system, to ensure that the database schema evolves in step with the application code.

Database regression testing: Ensure that the database schema actually works.

Configuration management of database assets: Your data models, database tests, test data, and so on are important project artifacts which should be managed just like any other artifact.

Database Schema Deployment: Ensure that the scripts used to build development environments are the exact same as the used in QA, UAT and production. Ensure deployment to production is not a surprise and not a project in itself.

is your database being tested and integrated like your application code? do you have a database integration strategy? do you have a process to upgrade your database as you make subsequent releases? Make the database part of your Continuous Integration cycle and benefit from it.

It?s considered very difficult to integrate the database, the way application developers integrate their code frequently. Pramod will describe a proven way to integrate the database with the application code and show a way to make it part of the same application code repository. The practice of "Continuous Integration" changed the way software is written, then why not extend the practice to include database in the Continuous Integration cycle, so that you can see integrated results of your application and database work.

Every time a new release of the application is deployed, invariably there are problems with the upgrade/migration of the database. Pramod will show how to create a process where you can upgrade your production databases using upgrade scripts created during development time and how these upgrade scripts can be tested so that you will save time and sleep when deploying applications into production.

As a series of recipes, Pramod will show how DBAs can be effective members of evolutionary teams, delivering value and expertise to the team, how your team can still be distributed across continents and be successful while evolving the database. The recipes are

Continuously Integrating Extracting your database in scripts Using Version control for your database Automating database or schema creation Creating objects in your database Removing database objects Removing your database Using the build.properties files Re-Creating your application database for any build Making it easy for new developers to join the team Integrating on every check-in Strategy for naming Upgrade scripts BuildNumber Timestamp UniqueIdentifier Release Automating Database change script creation Implementing database version checking Sending database upgrades to customers