Over the past few years I developed a handful of tools to help speed up development and deployment that I have already blogged about.
Recently I started working on a project that would run in Azure and had to find a way to make all these tools work in this enviroment. I'll step through each of the challenges I faced.
Database Migrations in Azure
Internally I have used AliaSQL to keep our databases in sync between developers and production systems. If you haven't read the AliaSQL article yet, take a few minutes to read over it. The TL;DR; version is that we maintain a set of good old SQL scripts in source control along with our code. When a database change is made in development, the developer commits the DDL script necessary to make this change. Each other developer will pull that change the next time they pull the latest code and then they can run a database update script to ensure they have the latest schema. Using AliaSQL, this script gets run in each environment so developers machines, test, stage, and production environments all have the exact same schema. No one ever has to manually make changes to the databases.
Unfortunately its not as easy to run a console app (AliaSQL.exe) in Azure as it is on my desktop or on my internal TeamCity build server so I needed a better way. This led to the creation of the AliaSQL C# runner tool which allows the web application to fire off the AliaSQL Update Database method. This way, if you push new code that has some database scripts, the web application can run those database changes automatically on app start. Intrigued? The AliaSQL-Demo project has some working examples of this here.
Multiple Instances of the Application
The next challenge was to enable multiple subdomains to point to the same application. I wanted to do something like client1.site.com and client2.site.com where both point to the same application but have their own distinct database.
I am using the standard Azure deployment slots to have a staging and production instance. I pointed the DNS with a CName for * to point to the Azure instance. This way [anything].mysite.com would work. I also set up a wildcard SSL certificate and attached it to the website.
The next challenge was making each hostname figure out which database to use. For this a I created a master database that has an entry for each valid host. On BeginRequest,I get the settings for the current host including the database connection information. Of course this is cached so it isn't a database lookup on every request.
Once per application start per Azure host, the AliaSQL c# runner fires to update the database with any new update scripts then cache that it has been ran.
The end result of this is each of the unique hostnames automatically apply the latest database schema changes on the first page view after the application is deployed - with zero intervention.
That makes for one codebase in one Azure website with a unique database per client. It is easy to maintain and easy to scale.
I may dive deeper in a future article if there is any interest.