One thing that recurs with me is that I always make mistakes with my deployments. Then I have to do them again time and time over. I’ve got used to deleting parts of the deployments which generally because we put together bespoke HPC implementations entail several SQL Azure instances, several storage account instances, ACS and Service Bus Queues. Of course that’s on top tens of cores in use by the deployment over three roles. The tedium of doing these things manually drove me to build in a transaction scope for deployments for Fluent Management. v0.4 will make the coming of age of Fluent Management. We’ve just uploaded v0.3.9.9 – yes we’re running out of numbers! This is now downloadable from nuget and can be used in an application preferably not production until we come out of beta but use it at your own risk.

Speaking of beta. We will be coming out beta by the end of June which should hopefully mark v0.5. This beautiful piece of software will be a lot more resilient and we’ll tying down the interface as much as we can going forward but probably won’t standardise it completely until v1. v0.3.9.9 is missing a transaction scope for deployments but includes it for storage and databases. You can couple as many creates as you want for these two types of service and if there is a failure at any point it will rollback. There are several other things that we’ve included as well such as low level control over config and support for plugins to name a couple. Some of the interfaces have changed and we’ve added some more commands which haven’t yet been wired into the fluent API. v 4 will see two things which ae absolutely mandatory, the first is error routing which will enable certain types of WebException to be handled. Polling asynchronously sometimes generates things like 404’s when resources have been deleted and yet the polls continue indefinitely. The other thing is the completion of the transaction scope for deployments. These two things will be like a coming of age for the library. After that it will be down to streamlining the interface. It’s a little too text oriented so we’ll be adding some Actions<> to help out.

To recap here is how you create a Sql Azure database:


var trans1 = sqlAzureManager.AddNewServer(Constants.LocationWestEurope)

.AddCertificateFromStore(TestConstants.ManagementThumbprint)

.AddNewFirewallRule("myofficeip", "10.27.27.253", "10.27.27.254")

.AddNewFirewallRule("anotherip", "10.27.28.11", "10.27.28.254")

.AddNewFirewallRuleForWindowsAzureHostedService()

.AddNewFirewallRuleWithMyIp("myhomeip")

.WithSqlAzureCredentials("ukwaug", "<a href="mailto:M@cc0mputer">M@cc0mputer</a>")

.AddNewDatabase("test")

.AddNewDatabaseAdminUser("ukwaugdb", "<a href="mailto:M@cc0mputer">M@cc0mputer</a>")

.ExecuteScripts(@"C:\Projects\Tech Projects\Elastacloud")

.Go();

And a storage account:


var storage1 = storageManager1.CreateNew("elastadfg1")

.AddCertificateFromStore(TestConstants.ManagementThumbprint)

.WithDescription("my new storage")

.WithLocation(Constants.LocationWestEurope)

.Go();

To couple these together in a transaction we create a ServiceOrchestrator like so:


var orchestrator = new ServiceOrchestrator();

orchestrator.AddDeploymentStep(trans1);

orchestrator.AddDeploymentStep(storage1);

var success = orchestrator.Commit();

Take a simple scenario here where we create our database server and database and boom! Our account limit for storage is breached. In this instance we want to rollback our database because half an application is not that much better than no application.

Anyway, happy trails and all that.