Team Foundation Server provides the core functionality for integrating all of the Visual Studio 2005 Team System parts/tools. One of the services available in Team Foundation Server is the “Source Code Control Service”. This service makes it possible to interact with the core source control features of Team Foundation Server.

A very cool feature of the Team Foundation Source Code Control is the check-in policy framework it provides. This framework makes it possible to set validation rules (policies) that must be satisfied before the developer is allowed to check-in his code. By using this feature you can make sure unit tests are available (and run) for the piece of code or that the code meets the FxCop rules. Also this framework provides us with some extension points that we can use to write our own policies.  

Unfortunately the policy can be overridden by the developer but in this case an e-mail is send to our good old project leader. This will give him the possibility to make sure the developer sticks to the policy the next time. The main purpose of the check-in policy framework is to support some sort of a process that ensures a certain level of quality of the code that is checked in by the developers.

Two important principles related to this checking policy feature are: policy definition and policy evaluation.

Policy definition; (for the control freaks among us) in this process it is decided which rules must be satisfied before the developer is allowed to check-in his code. Policy definition is very likely done by the architect or lead developer on the team.

Policy evaluation; this is the process that actually validates a check-in of the developer against the policies that are defined

Policy definition can be done from within Visual Studio Team System. Policies can be set on a project base by using the Team Explorer. Policies can be added, deleted or edited for a specific project.

The policies that are set for a project will be evaluated while the user is interacting with the Visual Studio IDE. This makes sure that every time a developer checks in a piece of code it validates against the set of rules/policies. Every policy (represented by a plug-in in the policy framework) receives the necessary information to determine if the code meets the policy. The policy plug-in can return information that can be used by the policy framework to display messages the user why the code doesn’t meet the policy. 

If you want more control, it is possible to write your own policies. These policies can be used by the policy framework. Basically all you have to do is implement a few interfaces and there you go. One of the things to remember is that the new policy plug-in has to be installed on all the client machines that must apply to this new policy. Team Foundation Server doesn’t provide a mechanism for distributing policies yet!

To create a new policy plug-in you can simply open a new Visual Studio project to create one or more classes that implement the necessary interfaces. To create a policy the following interfaces must be implemented:

IPolicyDefinition; this interface exposes some methods that are used in the policy defining process. The information provided by the methods of this interface is displayed in the user interface that helps defining a set of policies (within the Team Explorer) for a project.

IPolicyEvaluation; this interface exposes methods that are used to evaluate if the code that is checked in meets the policy. Methods in this interface accept the content of the actual check-in so this can be validated against the rules in the policy.

The policy framework makes sure that all classes that implement the IPolicyEvaluation interface receive the following information when a file (fileset) is checked in:

• The check-in comment
• The currently selected list of files
• The currently selected work items
• The release note information

The policy plug-in can use all of this information to decide if the infoset satisfies the policy.

Al assemblies that contain classes that implement the above interfaces will be picked up by the check-in policy framework. It is possible to have more that one policy plug-in in one assembly. Before the policy framework can pickup new policies it must know were to look for policy assemblies. Fur this purpose we have the good old registry, that helps Team Foundation Source Control service solve this problem. All we have to do is store a value (location) for the policy plug-in under a special registry key. At this moment the name of the key is “HKEY_LOCAL_MACHINE \Software\Microsoft\Hatteras\Checkin Policies”and HKEY_CURRENT_USER \Software\Microsoft\Hatteras\Checkin Policies. This will probably change because “Hatteras” is the codename Microsoft is using for the source control system!

If you are interested in the extensibility possibilities of the Team Foundation Source Control system (or any other Team Foundation Server services) go download the Visual Studio Team System Extensibility Kit and have a look!

Now I am busy with Visual Studio Team System for a while I suddenly realize that working in IT projects can become real different when working with new tool. This makes me wonder, will IT projects ever be the same?

When we have a look at an ordinary IT project there are a few things that often go wrong. First of all we have the project leader, according to the development team the project leader is most of the time a pain in the ass. He isn’t really involved in the development process and most of the time the he isn’t even aware of what the system really looks like. All he cares is his excel sheet (or ms project file) that indicates if the development team is working hard enough to meet the deadline. To gather the necessary information to update his excel sheets he drops by in the project room once ore twice a week to have a quick talk with the developers. When things go wrong all he does is blame the development team. When the project is delivered successfully it’s the project leader that gets all the credits.

To stay out of trouble, the development team informs the project leader during their weekly status meeting that development is right on schedule and everything goes as planned. “Just a few more weeks of development before we can start system testing” the lead developer says, just to make the project leader feel good. At the end of the status meeting the project leader reminds the development team about “their” motto: Work Harder!

After the project leader left the room, the developers thank the lead developer for not telling the project leader they are a bit behind on schedule. The lead developer says it is no problem but also indicates that starting from now on everybody (including himself of course) in the team has to work a little bit harder to keep the possibility to actually meet the planning. This means a little less playing darts, browsing the internet and writing blog entries during working hours. They all have a laugh while making some remarks that if they don’t meet the deadline they will do some development work during the system testing phase that is about to begin. So, no worries yet!

This is actually the moment that the eyes of the tester are opened! Till now the tester was just one of the guys in the team. While writing “his” test scripts using his own set of tools (like word, excel and some SQL scripts) he didn’t really bothered the developers so he was totally accepted. Every time the testers has a question about some functionality he is writing test scripts for, the developers told him this piece of functionality isn’t implemented yet (but, almost done!). Therefore the only option the tester has is to base his test scripts on the functional requirements that the functional designer of the team put in a special folder for him on the server.

Having heard the developers say that they will use “his” testing time to continue developing makes the tester pissed. From that moment on he realizes he isn’t a full member of the team anymore and swears to himself that he will do everything necessary to find a lot of bugs. That will force the developers to work harder to keep the all mighty project leader happy.

In the meantime, in his constant battle to keep the users happy, the functional designer is working hard on his own set of the functional specifications. Just some weeks before the deadline he sends the final version of the specs to the development team. Of course without notifying that poor tester working hard to create all kind of test cases that will definitely fail during the system test phase that is about to start. When the lead developer reads the new updated specs he starts complaining about the functional specifications include new functionality that is not part of the initial planning. Of course it is possible to include this in the release but this will affect the available testing time. After a small talk with the project leader it is decided not to change the deadline. The project leader learned never to leave his project plan so he thinks changing the deadline is evil! Feeling the pressure of the project leader and the functional designer the lead developers decides to implement the new functionality within this release. Because there is little time left he doesn’t change the class diagrams and all other related models and documentation that were initially created by the architect on the project. There will be plenty of time for this when the project is finished!

When the new functionality is finally included in the system, there is almost no time left for system testing. Some quick tests show that there are some bugs in the system but because the lack of time they are all marked as “low priority” so they can be fixed in the next release (of course this frustrated the tester even more). While some of the developers are helping the tester testing the software, others are building the install packages. When the packages are finally ready they are handed over to the operations department.

During the installation of the software all kind of problems occur. The architect decided to use some cool new framework and technology that, strange enough isn’t installed on the production environment yet. After some discussion with the operations department and some minor changes in the code the software can be successfully installed.

The very proud project leaders informs the user that the software is successfully, and of course, according to the planning, installed. This is the moment the users has his first look at the system. Because of the small delay in the development phase there was no time left for user acceptance testing. Luckily the project leader and the functional designer convinced the user (based on the functional design and some models from the architect) that the team is building exactly what the user wants. After playing a few hours with the system however the users realizes that this software isn’t what he wants. The system doesn't corresponds with his day to day job at all. One of the good things about this is that because the system isn’t very useful for the user, he will not find the bugs in the system and the project leader gets is changes to solve these issues in the next release of this beautiful piece of software.

So, what will Visual Studio Team System change in all of the above?

Unfortunately VSTS cannot change anything about the project leader. The good thing is however that VSTS brings us a totally integrated environment. This will dramatically improve communication between the different types of team members. The new set of tools will help improving the overall quality of the software.  

First of all the architect can use the different modellers available in Visual Studio Team Architect to model his applications. Together with the models provided by the operations department he can test the deployment of his applications in a very early stage of the project, which of course saves a lot of time in the end of the project.

After that the architect can use the class designer to model his classes. These models can be used by the developers to generate the code from. If the developers make changes in the structure of the classes VSTS immediately updates the models, initially created by the architect. So now the models and software are always in sink, saving a lot of time updating the models at the end of the project.

When using the MSF agile methodology within Visual Studio, all tasks are related to work items, which can be assigned to team members. The Team Foundation Server gives the project leader a way to monitor progress on work items. Also very nice report can be generated from this data giving the project leader the possibility to impress his users even more. Fortunately Microsoft will provide a separate tool for “project leaders”so they don’t need to use Visual Studio for that. This saves them from becoming a real team member.

The next good thing from MSF agile is that is provides a more flexible methodology which leaves some space for making changes during the project, for example to react on changes requests of users.

The new integrated test facilities and some support for Test Driven Development try to enforce that there is always a “working version” of the software. Maybe only a small piece of functionality is available but it works (because it is tested!). This gives the user the possibility to drop by in the project room any moment and ask for a quick demo of the software. Because the user sees what the system actually looks like in an early stage it is much easier to monitor if this is what he really wants.

Because within VSTS testing is fully integrated within the Visual Studio environment, communication between developers and tester (and all other team members) will improve. The tester might even have some .NET experience to validate or write the unit test for the software. Further, VSTS provides tools to force Unit tests to be available before it is possible to store the code in the version control system. The tester can use these unit tests to immediately start testing the software (and not wait till the end of the project).

The fully integrated version control system allows the team members to store all project related documents, code, etc. in the “project repository” which might help different team members using different versions of specifications.

So where are we?

All of these and a lot of other features of VSTS help us improve the overall quality of IT projects we are participating in the very near future. I haven’t yet real experience with this tool but I think is has enough potential.

For all the people every worked with me on a project:

Of course all of the above isn’t based on my own experiences. This is just what I heard from colleagues! I do like project leaders! For me Visual Studio doesn’t actually change anything in the projects I am participating in. The only difference is that when using Visual Studio Team System I have a totally new and cool tool to deliver these very successful projects to our clients!

To help developers (projects) deliver robust, industrial strength code, Microsoft's created her "defence in depth" strategy. This strategy aims to test for bugs at every stage in a project, aiming to catch them as early as possible. Microsoft thinks this can be done by:

•Unit testing, to test the basic functionality of every method

•Code reviews, to analyse code for coding errors prior to checking it in

•Frequent builds, to make sure that no changes have broken the application

The good thing about Visual Studio (Team System) 2005 is that it helps projects delivering quality code by providing a new set of tools.

 Let us look a little bit more to the new testing features of Visual Studio Team System:

Unit testing

Visual Studio 2005 not only includes a set of tools that better supports testing; it also supports the Test Driven Development (TDD) methodology. This methodology lets tests drive the production of code, ensuring that tests reflect what the code is supposed to do and that all methods in the public interface are tested.

Some of the essentials of TTD are:

• tests reflects the specifications and are written before any code that implements the requirements
• The aim is to pass the test
• Once all the tests are passes, the code is complete

One of the good things about unit tests is that it provides the possibility to execute regression tests during the life cycle of the project. This makes it fairly easy to ensure a change to one piece of code didn’t break any other piece of code. Another advantage of writing unit test (before the actual code!) is that this improves the overall design of the software. When using TDD, tests are always written before the code itself. The first time only a stub is created just to satisfy the compiler for the test. After that the body (implementation) is written of the code that is tested just until the test passes.

After the unit test passes, there is time for any refactoring of the code (if necessary) to improve the design.

TDD aims to create tests during development and not at the end of the project (if there is time left)

To make writing unit tests easier and more common, Visual Studio 2005 provides a unit testing framework out of the box. For those of you working with NUnit in the past, this framework will look very familiar. (Of course this is purely based on coincidence and has nothing to do with the inventor of NUnit now working for Microsoft.)

This unit testing framework is available in both the Team Developer and Team Tester of Visual Studio so unit test created by developers can be executed by the testers in the team. The testing framework and testing tools are fully integrated within the Visual Studio IDE so testing can be done without leaving Visual Studio.

When using Team Foundation Server (TFS), all gets even better. TSF integrates activities of the developers and testers; testers are notified when a developer checks in a piece of code (of course with the necessary unit tests!) and developers will be notified when the testers encounter a bug in the code. Without using TFS it is not possible to check in unit tests and test results cannot be stored in the projects repository.

When using the unit test framework within Visual Studio all test classes are stored in a separate assembly (at least this was what I found in the December CTP of VSTS). Personally I like the “strategy” of Enterprise Library a little better. Within Enterprise Library all test classes are provided within the implementation assembly. All in a separate folder within the project called “.Tests”. Maybe there is a very obvious reason to store the unit tests in a separate assembly but I haven’t found one yet.

The good thing is that there is a Test Explorer available within Visual Studio that makes it very easy to run a set of tests. This tool makes it even possible to only execute one or more categories of tests.

Another new and very useful feature of Visual Studio Team System is the integrated code coverage. This makes it very easy to validate if the unit tests for a piece of code cover all code paths. The actual Code coverage can be displayed in a percentage or within the code editor itself.

Knowing that Team System makes it possible to reject code that isn’t covered by unit tests for at least ‘x’ percent, it becomes more and more difficult to produce poor code!

During the first day of the Visual Studio 2005 Ascend training a basic overview was given of the Visual Studio Team System and .NET framework 2.0 features. The main purpose of this day was to create a mindset for all attendees to be prepared for the next three days.

Although the first day turned out to be pretty interesting, my main focus was on the three other days on which I planned to follow the “Tools and Integration” track, which covered Visual Studio Team System (VSTS) in more detail. 

It is my intention to write some more detailed postings about a few of the Visual Studio Team System features in the next coming days. First, a short list of some of the topics (without any detail) that were covered during the “overview day” of the Ascend training:

VB.NET/C#

Although it has nothing to do with VSTS or Whidbey I cannot forget the following statement I heard during the training. It is definitely not my intention to start the VB.NET versus C# debate again (and hurt anybodies feelings) but I have to admit, I totally agree with his statement J

‘The only reason VB.NET is there, is to make C# shine!”

Visual Studio 2005 Team System

Core Tenets:

• Quality
• Productivity
• Connectivity

Software lifecycle silos:

• Infra architect
• Testers
• Project leader
• Business analyst
• Developer
• Etc.

VSTS solves the communication problems between the different silos.

VSTS brings you:

• Design for operations
• Increased reliability
• Predictability
• Quality easily and often

Main goal: see how you are doing DURING the project on quality, performance, time, etc.

ASP.NET 2.0

The ASP.NET team set a few goals for their 2.0 release:

• Development productivity; Current claim: reduce 2/3 of lines of code needed to solve common issues compared to ASP.NET 1.1

• Administrating and Management; provide easy manage and administrating functionality (instrumentation, performance counters, etc.)
• Totally extensible platform; make it possible to replace an extend all build in functionality (by using provider model)
• Make it the World fastest app server

Smart Client

Benefits the rich clients and thin clients world.

It is NOT a product, it is architecture!

Two main designs:

• Data centric
• Service centric

Data centric: it is al about replicating the data. For example, replicate the data when laptop is connected using SQL CE.

Service centric: it is al about “storing the actions” (instead of data alone). Store the xml messages on smart client and “play” them against the server when connected.

System.XML

Design goals for System.XML:

• Performance improvement
• Enhanced security; in v 1.0 no security support. Now code access security for System.XML
• Enhanced schema support; infoset available in v 2.0
• More XSLT processing; 4 times faster

System.Data

Programming model:

• Provider factories (to write provider independent code)
• Provider enum

DataSet Enhancements:

• Peformance and scalability improvements
• Standalone datatable instances
• XML datatype
• User defined datatype in DataSet

Binary serialization of content (in v 1.0 always serialized to XML)

Pretty interesting first day but…. will be back with more info on Visual Studio Team System!

It’s been very quit on my blog lately. One of the reasons for this is the birth of my (first) daughter. I took some time off to fully enjoy taking care of her and get familiar to the fact that from now on there is another girl in my life J.

Next week I start working again and I think it will be a very interesting week. The company I am working for is participating in a Visual Studio 2005 Ascend program. As part of this program I am one of the lucky ones that can attend a (four day long) VS 2005 training. I will follow the “Tools and Integration” track of the course covering a lot of Visual Studio Team System related issues.  

I will post some of my experiences, thoughts and other Visual Studio Team System related issues in the next coming week!

This week I had to write a Software Architecture Document for a new project that I am assigned to. The document presents the high level architecture that will be used for the solution created in this project. The high level architecture identifies the services that are needed. These will be described in more detail (interface, messages, and implementation) at a later stage in a separate document.

When reading through the functional requirements I noticed the large number of reference tables that were described in the specs. All of this reference data is needed for (at least one of) the services and of course it has to be possible to maintain these reference data. This made me think about the best way to design this reference data within the high level architecture. After a talk with my colleague Gerke, I decided to do it in the following way:

Al reference data that is relevant for only one service will be maintained by the service itself. All reference data that is relevant for more that one service will be logically grouped in one service. For example, in the requirements for this project; country, region and sub-region reference data is described. For this, a ‘geography’ service (it’s only a name) is identified that maintains the country, region and sub-region reference data.

For this kind of reference data services, I identified two different interfaces types, one ‘query’ interface and an ‘update’ interface. Most of the service consumers of a reference data service are only interested in the query interface. The query interface is the one that will be used by a business information service to access the reference data. The ‘update’ interface will implement the so called CRUD service actions. This interface is only relevant for the one responsible for maintaining the reference data and therefore a little less important.

The same applies to reference data that is relevant to only one service (and therefore is maintained as part of the service itself). For this situation also an update interface is defined that implements the CRUD service actions for the reference data part of the service.

When implementing the reference data services, I think it is best to implement the query and the update interface in a separate ‘asmx’ file (when using .NET web services). This gives a nice and clean interface that is easy to consume for the service consumers providing them the service actions that they are interested in only. It also simplifies the authorization part of the two different types of service actions provided by the two interfaces.

During a recent project it became very clear to me that standardization (naming conventions, coding guidelines, etc.) is also a very imported issue within a service oriented environment. Probably because of the service orientation hype, everybody is too busy with all the service oriented related issues within the project that make them forget very basic things (like coding standards and guidelines).

Because of the autonomous nature of a service it is very likely that they are developed by different people (or teams). From what I saw in practise, communication between the several build teams of the different services within a solution is very limited, simply because of the fact that the interfaces are well defined (if the designer understands it’s job).  In case there is communication between the different service teams, it is mostly about the service interface and messages definition, rather than internal implementation (coding) issues. In case of a lack of standards, guidelines, etc., the end result of this is a solution (application) that exists out several services all implemented in a very different way, using different naming conventions, exceptions handling strategies, etc.

Of course missing standards and guidelines can cause the same issues (poor quality of code) in an “old fashioned” n-tier application but, because of the more tightly integration between the different parts or components in the application, developers tend to communicate more and they are more often (forced to) have a look at each other code. This will result in at least the same “standards and coding techniques” used within the whole application.

Because I have some time of in the last few days of this year I was looking for some coding stuff that I could do. To prepare for the (near) future, I decided to try upgrading the EDRA 1.1 bits to .NET framework 2.0. Just because I was curious how much time was involved in upgrading code like this. I installed the latest available release of Visual Studio 2005 and after opening the Reference Architecture solution in VS.NET 2005, the upgrading wizard left me with a little more than 100 errors and warnings. As you can see in the (very) short list below, most of the errors and warnings are because the EDRA bits are using 1.1 .NET framework parts that are obsolete in the .NET framework 2.0.

·          'System.AppDomain.GetCurrentThreadId()' is obsolete: 'AppDomain.GetCurrentThreadId has been deprecated because it does not provide a stable Id when managed threads are running on fibers (aka lightweight threads). To get a stable identifier for a managed thread, use the Thread object returned from Thread.CurrentThread.'

·          'System.Xml.XmlValidatingReader' is obsolete: 'Use XmlReader created by XmlReader.Create() method using appropriate XmlReaderSettings instead. http://go.microsoft.com/fwlink/?linkid=14202

·          'System.Xml.Xsl.XslTransform' is obsolete: 'Use System.Xml.Query.XsltCommand instead.

After a few hours of coding and searching the Visual Studio 2005 online documentation this is how (part of) my laptop screen looked like:  

I haven’t done any testing yet, I will do that the next coming days. But he.... at least it compiles!

I finally found time to do some testing with the ‘WSCF’ tool of thinktecture that Christian Weyer is blogging about. Installed the tool and followed the walk-through document. Cool!

Last week we decided to do an upgrade of EDRA 1.0 to EDRA 1.1 on our development machines. According to Microsoft, version 1.1 is the final version of EDRA. Microsoft indicates that in the beginning of next year they will start a similar project to take on the latest distributed design challenges using Microsoft’s BizTalk and "Indigo" technologies.

After making the change described my previous posting in the Microsoft EDRA 1.1 code, we compiled the EDRA 1.1 code using our own public key. After that we compiled our ‘EDRA extensions’ against the new EDRA 1.1 assemblies. Only one code change was needed to make all our code compile (Microsoft decided to change the name of one of the Handler Interfaces). Further the following changes were needed to make our test services work:

·         Remove ‘ra’ namespace prefix in ServiceReferenceArchitecture.config.

·         Move Pipeline configuration from ServiceReferenceArchitecture.config to the new ‘TemplateServices.config’ file.

·         Add two new configuration sections to specify the location of the ServiceReferenceArchitecture.config and the TemplateServices.config file.

Based on the results of our NUnit test, everything worked as expected (after the changes described above).

To make absolutely sure services implemented using EDRA 1.1 behave the same as services implemented using EDRA 1.0 we also did some manual testing against our test services. After that we had enough confidence to advice a project that is using EDRA 1.0 at this moment to do the upgrade to EDRA 1.1.

All the project has to do now is: install the new EDRA 1.1 assemblies; install the new version of our ‘EDRA extensions’; make the necessary changes in the configuration files; start system testing!