Home

Check out the Getting Started page for usage instructions.

I posted some details on why I did this on my office blog at http://sharpcoders.org/post/Introducing-AliaSQL

AliaSQL has its roots in Tarantino. Lifted from the original Tarantino documentation, here is the problem that Database Change Management is attempting to solve:

• Most significant business applications rely on at least one relational database for persisting data
• As new features are developed, database schema changes are often necessary – i.e. new tables, columns, views, and stored procedures
• Database schema changes and corresponding code changes must always be deployed together
• While deploying software to a production environment, code files and libraries may usually be deleted or overwritten - Database files, however, must be intelligently manipulated so as not destroy vital business data

The development tools available allow developers to make changes to their environment and do not address the problem of applying those changes to additional environments. (i.e. development, quality assurance, staging, production).

The solution to this problem:

Successful database change management requires that a consistent process be applied by all team members. Without a consistent process than the tools provided in this solution will not provide its full value.

AliaSQL change management consists of:

• Each developer using their own local database to do their development work.
• Each environment using it's own database. i.e. Development, Testing, Staging, Production
• Each developer maintains his changes locally. When the database changes are ready to commit alongside the application source code, the developer follows these steps:
• Create a change script that wraps all of the database changes into a single transactional change script. A Tool like Red Gate SQL Compare makes this a 30 second operation.
• Save the change script into a folder in your source tree call Update.
• Commit the change script along with the source code that corresponds to the change.
• The continuous integration server detects changes to the source control repository than it:
• It builds the application code.
• It executes the applications unit tests.
• Executes the database create task to create a new database with all of the changes that are in source control.
• Executes the projects integration (data access) tests.
• Marks the build a success when all the tests pass.
• Each developer runs the build script locally after receiving new schema changes scripts from the source code repository.
• The change management managers execute the script using the DatabaseDeployer tool to run the database scripts against the Dev, Test, and staging environments when the environments receive their next update of the source code.

Prerequisites

The following environmental conditions make the use of the database change management process frictionless.

• An automated build script. This includes compilation, unit tests, integration tests, versioning, packaging, publishing
• Source Control
• A continuous integration server that has a separate database instance dedicated to executing schema change scripts and integration tests
• A team that believes that a little process can go a long way.
• Separate environments for testers, marketing/content types, and staging.
• The will to do things better