Recently, my kids swim team needed a way to send out email, voice and text notifications from any mobile device. Other team’s were buying individual apps on phone market’s but we thought in this case, our own dedicated app would allow us to open access to all of the team captains as well as share costs. I thought a MVC 4 mobile site would provide a great experience across all mobile and desktop browsers as well as give me an excuse to try out Windows Azure Web Sites (WAWS).
Since this project will be a one-man show, I decided that I would use the Team Foundation Preview for source control and to manage defects and feature requests for each sprint. (Since this is a purely volunteer project, sprints are as long as I am feeling generous). It also helps to keep me organized since I don’t have a PM, or customer to keep me accountable. This also means that I get continuous builds and deployment built-in. This is the type of environment for small developer shops who need to focus on code, and let the hard work of system administration fall onto someone else’s shoulders. To provide this level of developer productivity, Platform-as-a-Service (PAAS) providers need to provide strict guidelines on what is and is not supported by their environment. I have found that these corner cases are what really defines the hosting experience, and generally specific features or configurations can’t be guaranteed until you try them out.
Step 1: Create a project and check it into TFS.
Login to Team Foundation Preview. If this is your first time logging in, you will need to create an account. For the Preview, all features are free. No word yet on the final pricing model, and what will be included in any MSDN/Software Assurance agreements.
Create a new team project. All you need to get started is a title for your project. You will also need to choose the process template TFS will use for your project. I’ll go with the default Microsoft Visual Studio Scrum 2.0. Add a short description and you are all ready to get started.
With TFS setup and ready to go, I can start up Visual Studio 2010 and choose “Connect to Team Foundation Server”. Add the account you just created in TFS preview as https://accountname.tfspreview.com. When you choose connect, you should see the project you just created. I create a MVC 4 mobile site from the new project menu and check-in the default site template to get started.
Step 2: Create a new website in the Windows Azure dashboard.
My first thought after signing on to the new portal is that it looked and felt much nicer than the old portal. It wasn’t until reading other blog posts about the portal that I realized it was rewritten in HTML5 rather than Silverlight. I didn’t mind the old portal, but the new experience oozes Metro cool and feels like I’m xboxing the cloud.
I register for the Websites feature in the preview area (the site says that it will email when my account is ready, but in my experience, it has been immediate) and create a new website. I provide the Url, and a user name and password for my SQL database.
Step 3: Link to TFS Publishing
From the website dashboard, if you look at the options on the right of the screen you will see an option to Set up TFS publishing. You enter your account for TFSPreview and select from existing projects.
When this is configured, there will be an initial build run titled projectname_CD (Content Deployment, I assume). This run is going to be what tests your build environment against that of Windows Azure Web Sites. I initially received some errors about missing assemblies. Grrr, I chose the defaults, and already I’m getting build errors.
I look into this a little bit, and it turns out I have an older version of Microsoft.Web.Optimization. The MVC4 mobile site template is already out of date. I love how quickly technology moves. By going into Package Manager and re-installing the offending package, the build errors should disappear and your site should be ready to go. If you want to avoid this type of error altogether, you can use Nuget Package Restore to avoid pushing assemblies to Windows Azure. I check my projects back in and …. success. By going to the deployments tab in the WAWS management tool, I can see that my site built successfully and has been deployed out to the URL I defined.
Super, I’m making progress. I start adding my logic to get the team roster out of the database and send notifications. I build successfully on my desktop and run a test. It works, so I check it in, and … the build fails again for missing assembly references. This time, I’m relying on private assemblies to do some work. I create a solution folder in my solution and add the private assemblies to the solution folder. This time when I check-in, the assembly can be resolved and my solution is deployed to the internet hosted safe and sound in Microsoft’s (US East) data center.
Developer-centric features like integrated source-control and continuous builds provide developers a major productivity boost when using a PAAS as opposed to “naked” virtual machines. Once assembly references were ironed out, it was smooth sailing, and WAWS would build and deploy in approx 2.5 minutes from initial check-in to complete deployment and active service on the public URL. When migrating projects over, or starting new projects, take your time to understand the build environment, and comb the logs for items that can be streamlined. Happy coding!!