Monday, July 30, 2012

Combining TFS, Visual Studio Scrum 1.0 and MS Project to manage a software project

There are a lot of benefits in tackling tasks based on priority instead of using task dependencies. After all, priorities change during the duration of a software project and it's difficult to keep tasks ordered sequentially. Getting your employer to buy in to using an Agile methodology to work on tasks based on priority will probably come with trade-offs. In my case the trade-off was that we had to use MS Project as well.


Here are a few things we learned while setting up a process:


1) Use leveling by priority in MS Project to avoid using task dependencies.


2) We had issues mapping priority fields between TFS and MS Project. In the end, we used to fields and had to keep them sync'ed (you can use a Macro for this).


3) The Scrum template in TFS doesn't allow you to log work. You'll need a custom column for this. This column needs to be mapped back to Project.


4) If you want to view a sprint burndown chart, remember to set the start/end date for the sprint.


We still have some unresolved issues:


1) We are not able to view the Release burndown chart.


2) If you are using baselines, you need to update the baseline before capturing hours in a task that doesn't exist in Project. That's because once you complete a tasks, the initial estimate is gone.


Anyways, I'm happy that the project is managed as "Agile" and take advantage of all the goodness of Scrum.

Continuous integration with SharePoint (and automated unit tests)

I've been working a lot with SharePoint lately and as with any project, we add it to our Cruise Control.NET server. The first challenge was that we had to install SharePoint on the CC.NET server. It was not really a challenge, but more of a time-consuming task.


The second challenge was setting up automated unit tests. In our case we use WCF services that receive an SPToken (actually, the string representation of the SPToken). This token expires every now and then, and we had to come up with a way to get a token in order to connect to a WCF service. The solution was creating a method in a service that creates a token and sends it back. It's really not the best practice, and it's not something you want to deploy to production, but it works fine for a continuous integration environment. These are the steps we followed:


1) Create a new service that is used only in the CC.NET sandbox
2) Create a method in that service that returns a token. The method should run with elevated privileges and return a token of a hardcoded user account (preferably an administrator account)
3) Reference this service from the project that contains the unit tests (we use XUnit)
4) Instantiate a service client from the test case (something like this)



  XUnitServiceClient client = new XUnitServiceClient("BasicHttpBinding_IXUnitService");
  client.Endpoint.Address = new System.ServiceModel.EndpointAddress("http://mypc/_vti_bin/XUnitService.svc/soap");
  string result = client.GetToken();



5) Then just call the method you're trying to test and pass the token.

Monday, July 23, 2012

SharePoint and WCF

I recently upgraded an ASMX project to WCF. It took me a couple of days (investigating, implementing and testing) to figure out, and although I'm sure my solution can still be polished, here are the steps so far to make it work:


1) Copy your .svc file to ISAPI


2) Make sure the markup of the .svc files is as follows


<%@ ServiceHost Language="C#" Debug="true" Service="MyApp.Service.TestService,  MyApp.Service , Version=1.0.0.0, Culture=neutral, PublicKeyToken=3333333333" %>


3) We are accessing the WCF services using jQuery, so we had to enable the webHttpBinding. Security needs to be enabled like this:



<security mode="TransportCredentialOnly">
  <transport clientCredentialType="Ntlm" /> 
</security> 



4) Create an endpoint behavior that includes


<webHttp />


5) Allow Anonymous Authentication on your IIS site.


6) Make sure you use the DataContract and DataMember directives where appropriate. You might get hard-to-debug errors when a type cannot be serialized correctly.


Along the way I learned a lot about Ntlm. At first I was getting a lot of "Unauthorized Access" responses, and I thought maybe using Ntlm was the problem. The real problem was that my WCF configuration was incorrect. Also, Ntlm is a protocol that uses a handshake, so you'll notice the same request three times at the beginning of the communication. Any subsequent request should only appear once.