Rinat Abdullin

Core change management principle
If an asset could change through the life-time of the development and its incorrect version could prevent the solution from being consistent and deliverable, then this asset should be versioned.

Overview
Databases always change during the development process. Those changes are usually related to the changes in the source code (i.e. existing table has been expanded with new columns and the source code was modified to access those columns). To avoid possible collisions between code and the database schema, all relevant database changes are to be versioned in the same repository.Relevant database changes are the changes that occur to the following database items:

• Global configuration
• Structure: Defaults, Logins, Rules, Stored Procedures, Tables, Triggers, User Defined Data Types, User Defined Functions, Users and Rules, Views
• Data: Static data (i.e. reference tables, dictionaries), Data storage format

Those changes are to be tracked and distributed via the scripts (either .sql or .NET) stored in the appropriate sub-project. That includes cases when the structure of the database does not change at all, but the format of the data is changed (i.e. instead of storing a number in an integer field a set of bit flags is stored there). In that case the script should upgrade all the data.

Every atomic change should be put in the separate .xml file with the predefined schema and name matching pattern “nnnn – ShortDescription.xml”, where “nnn” is consecutive number. File could contain one or more SQL and C#.NET scripts. No transactions are allowed!

.NET SqlArbiter utility should be used to perform manual database maintenance - version checks, upgrades, database rule checking and enforcement, reporting and script rollups. NAnt sqlchain task is to be used for integrating database-related tasks into the build process.