Migration

Writing a script to deploy a database is a hassle. But having to keep writing consecutive scripts to roll out schema changes, across several environment, is dangerous because errors are bound to happen. And I think it goes against what automation is about. I think it is unwise.

Or, actually, it is unWYSE.

WYSE takes a fundamentally different approach. One that is the good kind of automation, and because of that minimizes the chance of errors. The result is a 'sigh of relief' to work with if you are used to SQL deployment scripting.

In the following paragraphs we will get into why WYSE deployment and migration is THE way to go.

And be sure to check out the Trekkitopia demo as an "admin" to see a code example of deployment.

Declarative, Code-First, Idempotent

With WYSE, database deployment and migration is declarative, entity based. So your code is the Single Point Of Truth. The same entities and expressions in constructing SQL statements are used, with of course added entities that represent indexes, constraints, keys and what-not.

This is what happens during a WYSE database deployment/migration...

• The delta between your entities in code and in the database schema is figured out
• Pre-deployment checks/validations are done
• The actions needed sync the database schema with your in-code situation are determined
• The order in which those actions need to be executed is resolved
• The ordered migration actions are executed

The procedure described above is idempotent. Running the migration again is basically a NoOp. The advantage of this is that, instead of being a risk each time, migrating oftenly becomes a good thing.

Reporting And Dry-Runs

Deployment uses writers that execute the migration actions. Writers came in three flavors...

• SchemaWriter: This writer actually makes the database schema changes.
• ReportWriter: Makes a report of the changes; what type of change and the entity it pertains to.
• ScriptWriter: Records all the SQL statements that are executed during migration.

These writers can be chained, forming an execution pipeline. Typically the last one is the SchemaWriter. But when that one is omitted from the pipeline you have a DRY-RUN. This enables you to explore beforehand what would happen during an actual migration.

Entity Renaming Enabled

Where WYSE is truly unique is, even though it features an entity-based deployment instead of iterative, with supporting RENAMING of entities. It is declarative as well. Also, WYSE does it all in one go. So no second migration required.

Custom Validations

Pre-deployment, WYSE does a few standard validations to see if the deployment is good to go.

Which validations that are relies in part of the type of database. But you can add your custom validators.

Supported Databases

Currently WYSE supports deploying and migrating of the following databases:

• SQL Server
• MySql

Database Seeding

Usually a database devoid of any data is quite useless in the grander appllication scheme of things. Lookup tables, pre-existing configuration or whatever are needed.

To fill those tables, in WYSE you make your lists of the domain objects of which you want the data to be in the database. Then you can use WYSE's Upsert(ByKey) features to ensure the existence of those item rows in your database.

It is recommended to follow-up every deployment/migration with your data seeding to get a consistent, semantically correct database.

For an example of seeding you can go visit the Trekkitopia demo as an "admin".