Microsoft’s Brian Harry recently blogged ‘Announcing Continuous Deployment to Azure with Team Foundation Service’ in which he basically covers how you can now have a developer check in some code and see those updates on your Azure Websites hosted website within a very short time, basically however long it takes to compile and push up to Azure.
How to do it…
- TFS Stuff
- Add AzureContinuousDeployment.11.xaml to your BuildTemplates folder if you don’t have it already
- If you had to do step 1, then you will need to also register the Azure template for use. Start creating a dummy build definition and select the new template in the Process section. Once you have it there it’s ‘registered’ and you can discard the build definition
- Get an Azure account (if you have an MSDN subscription you get great free access thrown in)
- Enable the Websites preview feature under your subscription
- Create a Website
- Go to your website and Set up TFS publishing
- Work through the wizard adding the authorization details and choose your Team Project. When you are done the ‘magic’ will happen and you will see the following
- Linking it all together
This screen confused me a little. What it doesn’t tell you is that it created a build definition in your chosen project for you. The format is <WebsiteName>_CD
The first thing you are probably going to want to do is edit that builds Workspace Mappings as it defaults to the root of your project, i.e. a checkin ANYWHERE in your team project will trigger the build. (note there appears to be some logic involved here.. see further in the post)
If your Team Project has no solutions, your build definition will not have any Solution to Build defined.
Even though the build is not fully defined, if you check in anything to the Team Project it will trigger
Let’s add a solution to our Team Project
and check it in…. another CI build will trigger
Behind the scenes, when you checked in that solution file, TFS automatically associated the solution with the build definition….. and if you F5 your website ….. its got the new content!
That was EASY! You also get a log of your deployment in your Management screen
So what happens if we Set up TFS publishing to a team project which already has solutions…
I’ll disconnect TFS in the Dashboard
When you do this, TFS will disable rather than delete the build definition it created
If I Set up Publishing again it simply enables the build. I’ll delete the build so we are back to a position where we can compare linking TFS to a project.
If I do this, the build definition automatically adds my Solution to it’s template.
Not only that, it actually tried to be clever with the Workspace mappings… that’s cool!
Note though that if you have multiple _CD builds defined which have no solution to build, this solution will be added to all those builds (thanks Tiago Pascoal for pointing this out). That’s a bit of odd behaviour. I’d expect none to change in this case.
So what if we have more than one solution in our Team Project, something I’d expect most users to have…. The behaviour is the same as having no project. You get a build definition with no solutions defined and a workspace which includes your entire team project.
So that’s a quick ‘heads first’ dive into this new functionality. Overall I think it’s incredibly impressive and with a few tweaks to the fuzzy logic used it should ‘just work’ for those running multiple solutions in team projects…
This new functionality is not covered in the Release Candidate of the ALM Rangers Build Customization Guide, though I’m hoping we can get it in for RTM.
Now, I wonder what magic is hidden in this new build template….