Recently I have been working on a project where we needed to deploy both our Windows Azure and SQL Azure projects in a controlled and automated manner. We were already using Visual Studio Team Build for source control and doing simple gated check-ins. I wanted a way to easily use Team Build to handle the build and deployment for the Windows Azure and SQL Azure projects, and do so in a single step.
I was already aware of how to build and deploy a Windows Azure project by itself. Tom Hollander has a few great blog posts on how to do this. I pretty much followed what Tom outlined in his “Using MSBuild to deploy to multiple Windows Azure environments” post.
Deploying a SQL Azure project itself turned out to not be that hard either. Doing so was simply a matter of using MSBuild to call the “Build” and “Publish” build targets in the Microsoft.Data.Tools.Schema.SqlTasks.targets file (referenced from the .sqlproj file).
Individually the Windows Azure and SQL Azure projects are pretty easy to build and deploy. Doing so together was something I had a little more trouble figuring out. I’m sure this was partly due to the fact that I am NOT a Visual Studio Team Build guru. Heck, I hardly deviate from the normal default configuration!
After consultation with some more experienced Visual Studio Team Build folks at my company, the solution I ended up going with was to modify the default build template to branch the build logic depending on the type of project being built. If the project is a Windows Azure project (.ccproj), then execute MSBuild with a target and parameters to deploy to Windows Azure, and if the project is a SQL database project (.sqlproj) then execute MSBuild with a target and parameters to deploy to SQL Azure. Below are the steps taken:
- Create a new build template file, using the DefaultTemplate.xaml file as the base (create a copy of the DefaultTemplate.xaml file).
- Set the projects to build as the Windows Azure (.ccproj) and SQL database (.sqlproj) project files.
- Modify the build workflow in the XAML file to branch based on the type of project. There are two places in the build workflow where this will need to be done. The easiest approach, at least for me, was to slowly proceed down the workflow file until I found the “For Each Project in BuildSettings.ProjectsToBuild” sequence. I modified the default sequence to check if the project file ended with ”.ccproj” or ”.sqlproj”, and then run the appropriate MSBuild command for the project type.
Build Template Workflow - Before
Build Template Workflow - After
- Create two new build workflow arguments, SQLProjectDeployArgs and WindowsAzureProjectDeployArgs, that will be used to specify the arguments for MSBuild for each project type.
- Change the CommandLineArguments property for MSBuild to accept a new variable that is applicable for the Windows Azure or SQL Azure project. For example, the CommandLineArguments property for MSBuild associated with the Windows Azure project should read: “String.Format(“/p:SkipInvalidConfigurations=true {0}”, WindowsAzureProjectDeployArgs)“.
- Finished. Save the template file and make sure it is checked back into TFS.
- Edit the build definition
- Change the “Projects to Build” to include only the .ccproj and .sqlproj files.
- The build definition should now include two new parameters under the “Misc” section.
SQLAzureDeployArgs: /t:Build;SqlPublish /p:SqlPublishProfilePath="./Publish Profiles/MyProject.Database.Debug.Azure.publish.xml" WindowsAzureDeployArgs: /t:AzureDeploy /p:AzureManagementCertThumbprint="F908XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXAA1" /p:AzureSubscriptionID="0877xxxx-xxxx-xxxx-xxxx-xxxxxxxx1234" /p:AzureHostedServiceName="myproject" /p:AzureStorageAccountName="mystorage" /p:AzurePublishProfile="test"
In the end, the build definition looked like this:
Windows Azure and SQL Azure Build Definition
So far this approach seems to be working fairly well. The only problem I see now is if one of the projects fails to deploy and the other project succeeds, the deployment operation as a whole may report a failure. This seems to be more of a problem with the database deployment (e.g. a script is incorrect) than the Windows Azure deployment. One thing we’ll look at in the future will be to try to deploy the SQL project first, and then if that succeeds, then deploy the Windows Azure project. For now we just need to realize that even though Team Build may report a failure, a portion may have succeeded.
In the end, right now I’m fairly happy with this approach. It keeps the solution simple, which was a primary objective. I think this will be an easy to maintain approach as well. Are there more elegant solutions? Perhaps. How would you solve this problem?
