Garden management with Azure, Part 1

Create server project in VisualStudio (todo github link)

• Download the service quickstart from Azure
• Add connectionstrings for sql and azurestorage
• I changed ‘TodoItem’ to ‘Garden’ (DataObject, Controller, Context, Startup.MobileApp)
• In Startup.MobileApp, I remove the CicloGardensInitializer, because I don’t want the service to setup and fill the database automatically

Now it’s time for a first manual deploy of the service…

• Make sure you’re logged in to MSDN/Azure in VisualStudio
• in VisualStudio’s Server Explorer,under Azure – App Service, I find my App Service. In the contextmenu, you can download the publish profile
• In the solution explorer, right click the service project, select Publish – Import and open the downloaded profile
• After publishing, you should see a default azure website with a smiley

Now we should setup the migrations for EntityFramework. That’s important for making sure that the service models and the database tables are equivalent.

• Allow connections to the sql database from your working machine (azure portal – sql server – firewall – Add client IP)
• Package Manager Console
  • enable-migrations
  • add-migration (I used the name ‘First Setup’)

I prefer to run the migrations manually, because I also change the model implementations manually. But there are many possible approaches for this. It can be run automatically on startup of the service. Or through a deploy script for a productive environment. I do it manually with the command

• update-database

You will probably run into an error that cost me a loooot of time and nerves, until I found out what’s happening. It’s something about ‘clustered indices’. The problem is that when running migrations from the commandline against an Azure SQL database, the migration behaves different than when running from the service or when running against SQL Server. So you have to add this magic line of code in the constructor of the Configuration.cs class of the service:

SetSqlGenerator(“System.Data.SqlClient”, new EntityTableSqlGenerator());

After migrating, it’s time for closing the first circle, using a test project ‘CicloGardensService.IntegrationTest’. We want to make sure that all the migrations are really in the database, and that all CRUD operations for Garden objects are working through the service. So the first test class is called Database.cs. The only test is called MigrationsAreUpToDate, and this is what it’s doing:

• Instantiate an instance of Configuration.cs (the connection string must be in app.config of the unit test)
• get all migrations from the database, the local migrations and the pending migrations
• assert that local and remote migrations are the same
• assert that there are no pending migrations

So far, so good. But just checking the migrations doesn’t make sure that the actual POCOS and the database scheme are the same. If you made code changes, but forgot to create a migration for it, the last test won’t fail. For this, we really are going to establish a connection to the service, and perform the CRUD operations for the Garden class. The test class is called GardenControllerTest.cs, and I’ll be using a simple HttpClient, to not depend on the Azure SDKs and to really understand how the requests and Uri must look for the Azure service endpoints. This is what the tests are doing:

• Setup a HttpClient with necessary config in the constructor
• Method ‘Initialize’ that runs before each tests. It’s connecting directly to the database with EntityFramework, cleans up the ‘dbo.Gardens’ table and checks that it’s really empty. Like this, every test runs independently from the others, and can have precisely defined test data
• ‘PostGarden’ posts default garden objects to the service. Checks that the POST responses contain the objects including ‘Id’ and ‘CreatedAt’ timestamp
• ‘GetAllGardens’ posts the same default gardens. Then reads all gardens from the service and checks they’re complete
• ‘GetGarden’ gets one garden from the service and checks that its content is correct
• ‘PatchGarden’ posts the default gardens. Then creates a Delta<Garden> object containing overrides for the properties ‘Name’, ‘Longitude’ and ‘Latitude’ and sends a patch to the service. Then reads the same garden from the service and tests the overriden properties and that the ‘UpdatedAt’ field was changed
• ‘DeleteGarden’ posts all default gardens, deletes one of them. Then reads all gardens and checks that the deleted one is gone