If you are building a web application then one of the key things that needs to be done in the build and deployment process is manipulating a remote IIS server. Your requirements could be as simple as stopping and starting a website or as far as creating websites and application pools on the fly. As I’ve previously discussed the default TFS 2010 build template activities leave much to be desired in this area (read more here).  Lucky for us this is solved fairly easily with a mashup of technologies; Powershell 2.0, appcmd.exe, custom TFS build process templates and custom activities. In this simple example we will do a basic website deployment which includes stopping an existing remote website, deleting the existing files, coping our files to the deployment folder and starting the website back up…

The key to remote IIS administration is Powershell 2.0; it has the ability to run remote commands on servers using WinRM. To setup the build server and deployment server follow these steps. Note these are for Windows Server 2008 R2.

1. Make sure Powershell 2.0 is installed on both the build agent and deployment server.
2. Reduce the Powershell execution policy; in Powershell run the command set-executionpolicy RemoteSigned
3. On the deployment server you will need to enabled remote administration. The simplest way is to run the command winrm -quickconfig and follow the basic questions (all yes). This will enabled administration on HTTP and open a hole in the firewall.
4. Obviously make sure IIS in installed on the deployment machine.
5. Make sure the user that will be executing remote commands has the appropriate permissions on the deployment server. For me my user was TFSSERVICE and I gave it administrator rights on the deployment server. You can probably lock the permissions down further if you like.

As a test to make sure this is working outside of the TFS build process try this…

1. Create a test website (TestWebsite) on the deployment server (DeploymentServer)
2. On the build server open up a command prompt and run the command: icm deploymentserver “c:\windows\system32\inetsrv\appcmd.exe stop site TestWebsite”
3. On the deployment server check to see if the website is stopped; if it is then it worked and if not then you will need to debug

Once you have that working you can incorporate it into the TFS 2010 build and deployment system. To make my life easier I created a custom activity to easily execute remote commands; RemoteProcess.xaml. It wraps the InvokeProcess activity and constructs the appropriate Powershell command and handles the errors.

Now it is trivial to implement the above website deployment example. Using the RemoteProcess activity use these as the RemoteCommands and set the RemoteServer argument to DeploymentServer.

Stop Website

“c:\windows\system32\inetsrv\appcmd.exe stop site TestWebsite”

Start Website

“c:\windows\system32\inetsrv\appcmd.exe stop site TestWebsite”

You can see how powerful this is; now you have the ability to execute ANY command on the deployment server. Using this to administer IIS is just the start; this will be useful for SQL server database deployments, windows services, security… anything really.

UPDATE

After working with this for a bit I found a functional bug; the above solution does not return the remote command’s exit code. This is important so that you can have logic for success and failure of the remote command. The solution took me a long time to figure out! The new RemoteCommand should be…

“-noprofile -command “”$x = icm ” + RemoteServer + ” {” + RemoteCommand + “; $lastexitcode}; if ($x.length -gt 1){$x[0]}; exit $x[$x.length - 1]“”"

I created a few arguments on the RemoteProcess activity to support this, Output, Err and ExitCode. So to finish the above example of stopping a website would be…

powershell -noprofile -command “$x = icm DeploymentServer {c:\windows\system32\inetsrv\appcmd.exe stop site TestWebsite; $lastexitcode}; if ($x.length -gt 1){$x[0]}; exit $x[$x.length - 1]“

If your using TFS then you should get power tools. The version for TFS 2010 are out…

http://blogs.msdn.com/bharry/archive/2009/12/01/tfs-2010-power-tools-are-available.aspx

Also the best practice analyzer is out to make sure your server side is all good…

http://blogs.msdn.com/lszomoru/archive/2009/11/17/team-foundation-server-2010-beta-2-best-practices-analyzer.aspx

To build real world applications with TFS you will need to code some custom activities; the ones out of the box are not enough. There are several good resources for how to build these activities (see below). But there are some issues in Beta 2 that make the process a bit difficult. The issue is trying to get your custom activities to show up in the build process template workflow designer. Hopefully this gets fixed in the RTM version, but for now here’s what you can do.

Quick note about my setup, I have a single project that has all the custom workflow activities and several other applications that have their own builds that will use these activities. I dont want copies of my custom activities all over the place.

1. Create a central solution and project for your custom activities; call the project Workflow
2. Create your application solution and projects; lets call this solution Sunnyside.
3. Under your Sunnyside solution root create a folder called Build
4. Create a solution in this Build folder called BuildProcessTemplates
5. Branch the Workflow project to BuildProcessTemplates folder. (This allows you to have a central place to code your activities)
6. In this branched Workflow project create your custom build process template xaml files (Add them to the project; set the build action to None)
7. Now you will be able to open the BuildProcessTemplates solution, open the xaml file and be able to add the custom activities.

What a pain! Again, I hope this is fixed for RTM. Here are a few references…

How to create a custom workflow activity for TFS Build 2010

TFS Team Build 2010: Working with Custom Code Activities

MSDN Forum Thread

EDIT

After spending way too long on this Ive made some improvements. You dont actually have to branch the custom activities folder over, you can just add a DLL reference. The key is that in order to get the activities to show up in the toolbox you must use the “Choose Items…” -> “System.Activities Components” tab -> “Browse…” to the DLL. If you just add a normal DLL reference it wont work.

One of the new (and awesome) features of TFS 2010 is that you can create deep and complex relationships among work items of various types. This is needed to create rich project tracking and reporting. There isnt a TFS 2010 for Dummies book out yet and I needed a simple way to explain this. Pretty pictures to the rescue!

Here is a visual of how the work items are related. It can be complicated but it is this relationship structure that empowers the whole system. The work items under a user story (children) are either test cases or tasks. Tasks are for when someone needs to do something. Test cases are for things to validate for that user story to be functionally complete. As the tasks are completed, code is being written and functions start to work in the application. When all of the child tasks of a user story are completed, then the user story is code complete… meaning it can be tested. At this stage a tester will look at all of the child test cases of a user story and start to try them in the QA environment. As they find issues the will create bugs which are related to the test case (and associated user story). When all of the test cases are complete with no bugs and all of the tasks are complete it means a user story is complete (and should be working). Also notice there can be another dimension beyond parent and child, that of predecessor and successor. This is used when one task needs to be completed before another can start. An example of this is that a web page’s UI needs to be designed before it can be built. This is useful to determine the calendar date of when a user story will be complete. You can export all of this data to Excel and MS Project if you like.

A couple concepts that are not represented in this diagram code check-ins and builds. As code is checked into TFS it is associated with development tasks. Check-ins are rolled up into builds. Therefore you can garner all sorts of interesting data; bugs in a build, completed user stories in a build, work completed in a build…

Out of the box TFS ships the Task work item with two fields to support classification, Area and Iteration. It’s pretty obvious what Iteration is for (time), but Area can be a bit confusing. In my experience the issue stems from the fact that multiple user types use the TFS system. So you will get a different answer as to what an Area is based on the type of person you are talking with. People on the product & business side tends to think of areas as functional areas of the system (users, commerce, partners, advertising…); however people on the technical side tend to think of areas as the technical component (public website, database, api, mobile application…). Ive seen examples where companies just combined the two concepts into the Area hierarchy; this doesn’t really do anyone any good. The issue here is that these are really two different concepts with each task actually being associated with both concepts. Example; you can have commerce functionality in both the public website and the database. The solution is really quite easy, but nobody really does it… create a new work item field.

Customizing Work Item Types on Team Foundation Server

Field Definition

<FIELD name=”Component” refname=”TadlockEnterprises.TFS.Apollo.WorkItemFields.Component” type=”String” reportable=”dimension” >
<HELPTEXT>The techincal component.</HELPTEXT>
<ALLOWEDVALUES expanditems=”true”>
<LISTITEM value=”Public Website” />
<LISTITEM value=”Admin Website” />
<LISTITEM value=”API” />
<LISTITEM value=”Database” />
<LISTITEM value=”Foundation” />
<LISTITEM value=”Model” />
</ALLOWEDVALUES>
</FIELD>

Form Definition

<Group Label=”Classification”>
<Column PercentWidth=”100″>
<Control FieldName=”System.AreaPath” Type=”WorkItemClassificationControl” Label=”&amp;Area:” LabelPosition=”Left” />
<Control FieldName=”TadlockEnterprises.TFS.Apollo.WorkItemFields.Component” Type=”FieldControl” Label=”&amp;Component:” LabelPosition=”Left” />
<Control FieldName=”System.IterationPath” Type=”WorkItemClassificationControl” Label=”&amp;Iteration:” LabelPosition=”Left” />
</Column>
</Group>

In the TFS configurations I setup for my clients I have the Area field represent the business concept (because the hierarchy makes more sense here) and create a new flat field for the technical component (Component). I then add this field right next to the Area and Iteration fields in the UI. This Component field is also useful in the Bug work item.

All of this works pretty well. My only complaint with this is that you cant create custom work item fields that use the TreePath type, so you cant make the Component field a hierarchy. I’m sure there is some technical reason why this is the case, but Microsoft should just fix it.

Jim Lamb has a great write up on how to build custom workflow activities for TeamBuild for TFS 2010. Given that some key activities are missing out of the box in beta two, it’s very likely you will find yourself writing a few of your own.

http://blogs.msdn.com/jimlamb/archive/2009/11/18/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx

TFS TeamBuild has come along way with with 2010; the current version is almost a total rewrite of the previous versions. There are a ton of articles online about what’s great about the new TeamBuild (workflow, lab management, parallel tasks…), but I’m going to cover what’s not so great. Again Microsoft has really ignored the concept of application deployment and has just focused on compiling and testing. This is fine if you are building a DLL, but not if you are building a web application or database… or let alone an enterprises system. To be clear about what I mean by deployment; I’m referring to the process of taking built code and deploying it from a central server environment to the various code environments that exist in your organization (DEV, QA, PROD..). It really is a key step in the process… How are you supposed to test a N-tier web application without 1st deploying the web, service and database components? The closest they come is the new Lab Management functionality; but this is far more focused on managing virtual machines. They should have separated this all out… activities around TFS, activities around compiling, activities around the file system, activities around testing, activities around IIS, activities around databases and activities around virtual servers. A good example on how the default template is almost useless out of the box is that all the outputs from EVERY project in your solution get dropped into one big flat directory. This is the same behavior as in previous versions. What you really want is a folder for each application. this would make it easier to bridge from building to deploying as you have a folder that represents the output of a deployable component that can be copied to another server. You can see my MSDN post about this here…

http://social.msdn.microsoft.com/Forums/en-US/tfsprerelease/thread/9173d13f-88c0-4060-8bbd-2826e2eac8c8

Luckily though this all can be fixed; albeit with some work. It is possible to create both your own workflow activities and your own build process workflows. So I dove into the default build process template to understand what is going on there. From there I’ve started to create my own build process workflow. It’s a work in progress, but for now it at least drops each application’s output into it’s own directory in the drop folder. I will be adding the deployment and test tasks next.