Thursday, 17 August 2006

Team System Event on Friday 8 September 2006

On Friday 8 September 2006 I will be delivering a a one-day VISUG event at the Compuware offices.  During this event we will provide our VISUG members with deep dive information on Visual Studio Team System 2005. Since this is a community event, we directly skip all formalities and focus on what is really important:  The attendee will acquire the knowledge to be productive on a team that uses Visual Studio 2005 Team System.

During the event we will discuss following topics:

  • Event Overview : Overview, Business value of VSTS, core scenarios, licensing
  • Planning for VSTS: Hardware and software requirements, selecting projects or solutions
  • Deploying & Maintaining Team Foundation Server: Installation, Administration, backup and restore
  • Working with Team Foundation Server: Architectural overview, services, extensibility
  • Team Projects & Reporting: Project planning, methodology, reports
  • Process Template Customization: Process guidance, work item types, workflow
  • Source Code Control: Overview, migration, administration
  • Building Code (MSBuild): Overview, customization
  • Architect Tools: Application designer, class designer, logical datacenter designer, SDM SDK
  • Developer Tools: Profiling, code coverage, code analysis
  • Visual Studio 2005 Team Edition for Database Professionals
  • Testing Tools: Test management, test types, unit testing
  • Integration Scenarios: Commonly encountered integration scenarios

This training is free of charge to all our VISUG members.  You can register at http://www.visug.be/CommentsView.aspx?Id=83ab000e-8475-4e46-b642-ac9855b891f2.  Be aware that there is a maximum of 40 attendees for this event so register as soon as possible.


Team System | VISUG
08/17/2006 19:07:17 UTC  #  Comments [0] 
 Wednesday, 09 August 2006

How to retrieve all event subscription made in Team Foundation Server

On of the extensibility features of Team Foundation Server is the ability to subscribe to Team System Events.  To my knowledge you can manage these subscriptions with the BisSubscribe.exe command-line utility, the client API’s or the EventService web service.   You use these tools to retrieve event subscription information if you provide the information on who created the event subscription or the subscription ID. 

Unfortunately they do not allow you to get a list of all the event subscriptions that are made on a particular team foundation server.  This can come in handy when you need an overview of and maintain the list of subscriptions on your server.  Since there is no standard way to accomplish this, I arranged a get together with my good friends Mr. Reflection, Mr. Private Method, Mrs. Internal Method and Mrs. Private Field and we came up with the underlying code sample which returns the event subscriptions for your Team Foundation Server:

/// <summary>
/// Gets all <see cref="Subscription"/> instances for a team foundation server
/// </summary>
private Subscription[] Subscriptions()
{
// 1. Get an instance of the types on which we will perform reflection
// The SubscriptionOnServer contains the logic for retrieving event subscriptions
Type subscriptionOnServerType = typeof(SubscriptionOnServer);
// The SubscriptionOnServer contains the logic for executing stored procedures
Type dbType = subscriptionOnServerType.Assembly.GetType("Microsoft.TeamFoundation.Server.DB");

// 2. Get an instance of the subscriptionOnServer class through its factory method
MethodInfo serivceMethod = dbType.GetMethod("Service", BindingFlags.Static | BindingFlags.Public);
object service = serivceMethod.Invoke(dbType, null);

// 3. Initialize the connectionstring property of the DB class
MethodInfo initMethod = dbType.GetMethod("Init", BindingFlags.Instance | BindingFlags.NonPublic);
initMethod.Invoke(service, new object[] { ConfigurationManager.AppSettings["ConnectionString"] });

// 4. Retrieve all the subscriptions on the server
MethodInfo AllBareSubscriptionsMethod = subscriptionOnServerType.GetMethod("AllBareSubscriptions", BindingFlags.Static | BindingFlags.NonPublic);
ArrayList allSubscriptionsOnServer = (ArrayList)AllBareSubscriptionsMethod.Invoke(subscriptionOnServerType, new object[] { });

// 5. Get the FieldInfo information for the internal subscription field on the SubscriptionOnServer type
FieldInfo subscriptionField = subscriptionOnServerType.GetField("subscription", BindingFlags.NonPublic | BindingFlags.Instance);

// 6. Get the Subscription representation of the SubscriptionOnServer instances that were retrieved
Subscription[] allSubscriptions = new Subscription[allSubscriptionsOnServer.Count];
for (int idx = 0; idx < allSubscriptionsOnServer.Count; idx++)
{
SubscriptionOnServer currentSubscriptionOnServer = (SubscriptionOnServer)allSubscriptionsOnServer[idx];
Subscription currentSubscription = (Subscription)subscriptionField.GetValue(currentSubscriptionOnServer);

allSubscriptions[idx] = currentSubscription;
}
return allSubscriptions;
}

You also need an application configuration file that looks this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

    <appSettings>
        <add key="ConnectionString" value="Application Name=TeamFoundation;Persist Security Info=False;Initial Catalog=TfsIntegration;Data Source=QUAOAR;Integrated Security=SSPI"/>
    </appSettings>

</configuration>


 
SCM | Team System
08/09/2006 11:29:59 UTC  #  Comments [0] 
 Tuesday, 04 July 2006

Work Item Association during check-in

Visual Studio 2005 Team System allows you to add the work item association check-in policy, to your Team Project. It requires you and other team members to associate a work item with each check-in, which is great. 

 

However, it does allow you to associate work items from a team project that is different from the one your changes belong to.  If you have 2 team projects A and B, you are allowed to associate a work item from team project A with changes that were made in team project B.

I’m looking for a valid reason why this should be allowed, so if you have an idea as to why, do not hesitate to help me out here…

Despite the fact that there could be a valid reason to do this, I created a check-in policy that ensures you that you are only allowed to associate a work item for the team project to which the changes belong.  This means you can only associate work items for team project A with changes from team project A.

Update: Removed duplicate PolicyFailure entries.

using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;
using System.Windows.Forms;

using Microsoft.TeamFoundation.VersionControl.Client;

namespace CheckForCommentsPolicy
{
/// <summary>
/// This policy will check if there is a relationship between the team project to which the pending changes belong to and the team project to which the work items associated with a check-in belong.
/// </summary>
[Serializable]
public class ValidateWorkItemAssociation : PolicyBase
{
/// <summary>
/// Creates a default instance of the <see cref="ValidateWorkItemAssociation"/> class.
/// </summary>
public ValidateWorkItemAssociation()
{
InstallationInstructions = @"Create a new string value under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Checkin Policies]\nKey: ValidateWorkItemAssociationPolicy\nValue: full name of the ValidateWorkItemAssociation.dll file.";
}

/// <summary>
/// This string is a description of the type of our policy. It will be displayed to the
/// user when they select our policy type in the list of policies installed on the system
/// as mentioned above.
/// </summary>
public override string TypeDescription
{
get { return "Checks the relation between the pending changes and the related work items"; }
}

/// <summary>
/// This is a string that is stored with the policy definition on the source
/// control server. If a user does not have our policy plugin installed, this string
/// will be displayed. We can use this as an opportunity to explain to the user
/// how they might go about installing our policy plugin.
/// </summary>
public override string InstallationInstructions
{
get
{
return base.InstallationInstructions;
}
set
{
base.InstallationInstructions = value;
}
}


/// <summary>
/// This string is the description of the policy. It will be displayed to the user in a list
/// of all installed policy types when they are creating a new policy.
/// </summary>
public override string Description
{
get { return "This policy will check if there is a relationship between the team project for the pending changes and the team project of the associated work items."; }
}

/// <summary>
/// This string is the type of our policy. It will be displayed to the user in a list
/// of all installed policy types when they are creating a new policy.
/// </summary>
public override string Type
{
get { return "Check the relation between the pending changes and the related work items."; }
}

/// <summary>
/// This method is invoked by the policy framework when the user creates a new checkin
/// policy or edits an existing checkin policy. We can use this as an opportunity to
/// display UI specific to this policy type allowing the user to change the parameters
/// of the policy.
/// </summary>
public override bool Edit(IPolicyEditArgs policyEditArgs)
{
// no configuration to save
return true;
}

/// <summary>
/// This method performs the actual evaluation. It is called by the policy framework at various points in time
/// when policy should be evaluated. In this example, we invoke this method ourselves when various asyc
/// events occur that may have invalidated the current list of failures.
/// </summary>
public override PolicyFailure[] Evaluate()
{
// Make sure we are notified when the user changes his selection of work items
this.PendingCheckin.WorkItems.CheckedWorkItemsChanged -= new EventHandler(CheckedWorkItemsChanged);
this.PendingCheckin.WorkItems.CheckedWorkItemsChanged += new EventHandler(CheckedWorkItemsChanged);

List<PolicyFailure> failures = new List<PolicyFailure>();

foreach (WorkItemCheckinInfo info in this.PendingCheckin.WorkItems.CheckedWorkItems)
{
if (PendingCheckin.PendingChanges.AffectedTeamProjectPaths.Length > 0)
{
// Get the affected team project path for the first check in
string affectedTeamProjectPath = PendingCheckin.PendingChanges.AffectedTeamProjectPaths[0];
Regex matchTeamProject = new Regex("[^$/][^/]*");
// Retrieve the team project name for the pending change
string affectedTeamProjectName = matchTeamProject.Match(affectedTeamProjectPath).Value;
if (affectedTeamProjectName != info.WorkItem.Project.Name)
{
failures.Add(
new PolicyFailure(
string.Format("Work item with ID '{0}', is not a work item for team project '{1}'.",
info.WorkItem.Id, matchTeamProject.Match(affectedTeamProjectName).Value)
, this)
);
}
}
}
return failures.ToArray();
}

/// <summary>
/// This method is called if the user double-clicks on a policy failure in the UI.
/// We can handle this as we please, potentially prompting the user to perform
/// some activity that would eliminate the policy failure.
/// </summary>
public override void Activate(PolicyFailure failure)
{
MessageBox.Show("Please associate a work item that belongs to the same team project as your pending changes.");
}

/// <summary>
/// This method is called if the user presses F1 when a policy failure is active in the UI.
/// We can handle this as we please, displaying help in whatever format is appropriate.
/// For this example, we'll just pop up a dialog.
/// </summary>
public override void DisplayHelp(PolicyFailure failure)
{
MessageBox.Show("This policy helps you make sure that you associated work items to a check-in that belong to the same team project as the pending changes.", "Prompt Policy Help");
}

/// <summary>
/// Called when the user changes the work item selection during a check-in
/// </summary>
private void CheckedWorkItemsChanged(object sender, EventArgs e)
{
this.OnPolicyStateChanged(Evaluate());
}
}
}



SCM | Team System
07/04/2006 09:31:25 UTC  #  Comments [2] 
 Monday, 03 July 2006

Summary Visual Studio Team System - Event

I had a blast this weekend during the VISUG the Visual Studio 2005 Team System Event. About 20 people sacrificed their Saturday to put their minds on Visual Studio Team System. All attendees received a free copy (thanks to MSDN Belgium) of Professional Visual Studio 2005 Team System.

 

On Friday we focused on what Team System is and how it’s composed, we took a deeper look at the Project Managers role in the entire process, and finished the day with demos on work item, process, report and portal customization.  We continued at Saturday morning (the goal was 9 AM, but we missed that target by about 20 minutes, by no fault of my own ) with a look on the Architects role by walking through the functionalities that is provided in the Architect edition.  Our VISUG members did not hesitate for a second to ask me all sorts of questions on the architect edition and I could immediately notice that they were exited by the product and its possibilities.  We discussed the Developer and Tester editions by doing demo’s and walking through the product.  The demo’s were pretty much on demand, so it was quite a challenge for me to get them working :-) 

 

Do you know when it’s a truly live demo?  When the audience asks a questions and the speaker gets so exited about that question, that he totally changes his demo and starts working on a solution together with the help of his audience… and they continue working on it during the break!

 

I hope you all got really exited about Visual Studio 2005 Team System and learned a lot about the product.  If you still have any questions that you would like to see answered, do not hesitate to mail me at Steven.Wilssens@telenet.be.  I will create a detailed post about the topics we discussed, and I’m writing a summary for the VISUG website, so stay tuned…

 

I had a really good time during my VSTS weekend and I hope all attendees have the same feeling about it!

 

PS: Here are 2 photo's from the event: VSTS_Event_01.JPG (42.07 KB) and VSTS_Event_02.JPG (44.52 KB).


Team System | VISUG
07/03/2006 08:47:40 UTC  #  Comments [2] 
 Thursday, 29 June 2006

Visual Studio Team System 2005 – Event
Tomorrow (06/29/2006), I’m presenting the first day of the VISUG event on Visual Studio Team System. Psst I’m getting used to the US date-time notation We will have a very diverse audience ranging from developers to sales people, VSTS rookies to VSTS experts… I’m really looking forward to the challenge of making all of our members leave with that happy VSTS feeling…
Team System | VISUG
06/29/2006 19:16:34 UTC  #  Comments [0] 
 Friday, 23 June 2006

Reminder: Visual Studio Team System Workshop by VISUG

Reminder:

 

The Belgian Visual Studio User Group organizes a 1 ½ day seminar around Visual Studio Team System on 30 June and 1 July.  There are still some seats available, so if you are interested in learning about Team System in a User Group kind of way (real high risk live demo's, with live coding and hopefully a happy ending :-) )

 

Description:


This day and a half community event provides VISUG members with deep dive information on Visual Studio Team System 2005. During this event we will demonstrate the capabilities Visual Studio Team System 2005 in a way only user group can: not in theory but by live examples.

 

Event Outline:

        Event Overview : Overview, Business value of VSTS, core scenarios, licensing

        Planning for VSTS: Hardware and software requirements, selecting projects or solutions

        Deploying & Maintaining Team Foundation Server: Installation, Administration, back up and restore

        Working with Team Foundation Server: Architectural overview, services, extensibility

        Team Projects & Reporting: Project planning, methodology, reports

        Process Template Customization: Process guidance, work item types, workflow

        Source Code Control: Overview, migration, administration

        Building Code (MSBuild): Overview, customization

        Architect Tools: Application designer, class designer, logical datacenter designer, SDM SDK

        Developer Tools: Profiling, code coverage, code analysis

        Testing Tools: Test management, test types, unit testing

        Integration Scenarios: Commonly encountered integration scenarios

 

When:


Friday 30 June 2006 from 13:00 until 17:00
Saturday 1 July 2006 from 9:00 until 16:00

 

 

Where:


Compuware Belgium

 

How to register:
Send an email to Steven Wilssens, which contains your name and the fact that you want to attend the event. Remember, there are 30 seats available for this event, so register as soon as possible.

 

Subscription Fee:


As with all Visual Studio User Group events, it is available to our Visual Studio User Group Members at no cost.


SCM | Team System | VISUG
06/23/2006 08:47:09 UTC  #  Comments [0] 

Team Foundation Server MSSCCI Provider

The Team Foundation Server MSSCCI Provider enables integrated use of Team Foundation Version Control with products that don't support Team Explorer integration. 
The previous version already supported Visual Basic 6 SP6, Visual Studio 2002, Visual Studio 2003, SQL Server Management Studio,...  
I'm pretty exited about the latest version which was released on 6/21/2006.  This release does not only include additional support for PowerBuilder, Enterprise Architect, but also an improved Open from SCC experience, Work items can now be modified in the checkinwindow, Get latest on checkout support,  Check-in lock is treated as exclusive, and the setup now works on works on x64. 

You can download the TFS MSSCCI provider here.


Team System
06/23/2006 08:39:39 UTC  #  Comments [1] 
 Friday, 07 April 2006

MVP Visual Developer - Team System

Yesterday, Tom Mertens announced that Microsoft nominated 2 new MVP's for Belgium.  If you read Tom's post, you will know that the first new MVP is Mieke Verburgh.  But who's the second?  On Tuesday I received the news that I'm the second Belgium that was awarded with the Microsoft Most valuable Professional (MVP) Title.  I’m now an MVP in the Visual Developer - Team System domain.  As you can imagine I am really thrilled to get rewarded this way. This is an extra boost for me to provide you with as much information I have on Team system and continue the Belgium Visual Studio User Group initiative.  A lot of people provided me with an amazing amount of support during the past months, but I would especially like to thank Annemie Vandenberghe who is the Human Resource Manager at Compuware and one of the thriving forces of Compuware and the Belgium Visual Studio User Group.  If you are interested in becoming a member of the Professional Services Department at Compuware, just send her an email and hopefully we’ll meet during one of the following interviews 

 

From the marketing trenches about the MVP program:

 

The Microsoft MVP Program is a worldwide award and recognition program that strives to identify amazing individuals in technical communities around the globe who share a passion for technology and the spirit of community. Microsoft MVPs are recognized for both their demonstrated practical expertise and willingness to share their experience with peers in Microsoft technical communities.


Team System
04/07/2006 07:03:02 UTC  #  Comments [8] 
 Wednesday, 15 March 2006
 Sunday, 05 March 2006

Sildes: Advanced Source Control: Beyond CheckOut and CheckIn

During the Belgium Developer and IT Pro Days , I’ll be presenting my session on Best Practices for Advanced Source Control: Beyond CheckOut and CheckIn. I think I’m pretty close to the final version of the slides but would really appreciate your feedback! So it would be very much appreciated if you could download the slides and leave a comment or send me an email.

Update: You can find the updated presentations in: PART I and PART II.


SCM | Team System
03/05/2006 20:37:58 UTC  #  Comments [0] 
 Thursday, 08 December 2005

Data Mining with Team System and Microsoft Office Excel 2003
One of the great features of Team System is the extensibility of its reporting infrastructure. It includes a data warehouse in which data from work item tracking, version control, builds, and testing tools are stored. The data warehouse includes both relational and analytical process (OLAP) databases. This provides you with enormous potential for creating you own reports. What I want to show you in the following example is how you can use the analytical process database and show it in a PivotTable report. PivotTable reports organize and summarize your data so that it doesn't just sit on a worksheet gathering dust. We will retrieve a list of ChangeSets, with the names of the modified files, the number of lines that were added, modified, and removed, for the available team projects:

Cryptic Error Messages:
• Step 6 If you get “Initialization of the data source failed", you need to reregister Microsoft OLE DB provider for Analysis Services 9.0. Depending on your installation location following command will help you out: regsvr32 "c:\program files\common files\system\ole db\msolap90.dll".
• Step 8 If you get “an error occurred in the transport layer”, you very likely did not enter a correct user name/password combination.


Steps:
• Step 1 Start Microsoft Excel.
• Step 2 From the menu select Data > PivotTable and PivotChart Report.
• Step 3 In the PivotTable and PivotChart wizard dialog select External Data Source and click the Next.

• Step 4 Notice that the text next to the Get Data button indicates that no data fields have been retrieved at the moment.

• Step 5 Click the Get Data button.
• Step 6 Click the OLAP Cubes tab, Select and click OK.

• Step 7 In Field 1 enter TeamSystem (or any name you want to give it). For field 2 select Microsoft OLE DB Provider for Analysis Services 9.0 and click Connect.

• Step 8 Make sure Analysis server is selected and enter the server name in the Server field. For User ID enter TFSREPORTS and enter the designated TFSREPORTS password in the Password field. Click Next.

• Step 9 Make sure TFSWarehouse is selected and click Finish.

• Step 10 You should see that TFSWarehouse is displayed after the Connect button. Make sure that the Team System cube is selected. Check the Save my user ID and password checkbox and click OK.

• Step 11 IN the Choose Data Source dialog click OK.
• Step 12 In the PivotTable dialog click Finish.
• Step 13 From the PivotTable Field List, double-click each of the following nodes in this order:
Team Project.Team Project
Changeset
Filename.File Path
Lines Added
Lines Modified
Lines Deleted.
It is possible that not all required fields are present in you current PivotTable Field List. The necessary steps, to add the missing fields, are described in the How to add a  Field to the Team System Cube post.

Close the PivotTable Field List window.
• Step 14 Enjoy your great new PivotTable!

Team System
12/08/2005 18:18:37 UTC  #  Comments [1] 
 Tuesday, 20 September 2005

PDC05 - Software Development with Visual Studio Team System

During the Professional Developers Conference, I attended the excellent pre-conference session on Software Development with Visual Studio Team System. The session was delivered by Richard Hundhausen and Steven Borg. Their presentation was divided into two main parts:

A two hour theoretical introduction to Visual Studio 2005 Team System;
A four hour end-to-end demo on how to build a distributed application using Team System.

In the first part they started by summarizing the different challenges that companies encounter while building distributed solutions: lack of communication; lack of tool integration, lack of (good) process guidance, and the need to increase the predictability of success.
Steven continued by stating that about 70% of private and about 90% of all government software development projects, still actually fail.
After these chocking figures we composed a definition of Team System as being an integrated suite of tools to support the entire software development lifecycle. Although I think we will only accomplish this in future versions of Team System, the current version is an incredible starting point.
As you undoubtedly know Microsoft will provide the Visual Studio Team System front-ends in basically 3 different editions:

Team Edition for Software Architects
Team Edition for Software Developers
Team Edition for Software Testers
You can get the sum of all of the functionality provided by the abovementioned in the Team Suite Edition.

Our speakers covered the different features for each edition and continued by covering the different areas where Team Foundation Server will provide you with huge productivity improvements:

Collaboration
o Work Item tracking:
Scenarios, Quality of Service Requirements, Risks, Tasks, Bugs, Custom work items
o Reports
Software Configuration Management
o Merging, branching, shelving, etc
Build Management
With a room full of developers, you could not continue the session without explaining how the Team Foundation Server provides all the abovementioned functionality. They did this by explaining the Team Foundation Services Architecture and made a very important remark if you want to talk to these services yourself: despite the fact that these services are exposed as web services, developers are highly encouraged to use the provided Team Foundation Object Model since it provides you with process orchestration which you would be missing if you would decide to talk to the web service directly by creating your own proxies.
In the following minutes we stopped in the land of the Software Configuration Manager where they explained the Team System’s Version Control System and compared it to Visual SourceSafe 2005. As a conclusion I can say that Visual SourceSafe 2005 is definitely a huge improvement on its predecessors, but is still relies on the file system for its storage, whereas Team Foundation Version Control is in a league of its own and uses SQL server 2005 as its storage provider.
One of the great things about Team System is that it’s not a locked down platform but that it’s extensible in almost any way you can imagine. There is an exhaustive eventing model and as I mentioned before you can use the many API’s that are exposed. It is also possible to extend Team System by providing you own methodology templates. You can also use the different extensibility toolkits that are available today and will be part of the actual Team System SDK. It is very reassuring to hear that a lot of VSIP partners are planning on extending Team System which definitely proves that they believe in its future.
During the remainder of the introduction Steven and Richard covered the different editions of the Team System front-ends:

The first edition they tackled was Team System for Project Manager which might seem a bit strange since there is no direct mapping to a Team System Edition. A combination of the Team System Client, the Team System functionalities provided in Excel and MS Project will make a project manager a respected member of the Team System family. Following activities available to a project manager were discussed and illustrated:

The creation and configuration of team projects;
Creation and Assignment of work items;
Project status monitoring by querying work items or viewing reports on the project portal. You have many different reports but if I have to pick a favorite it would be the code churn report, which Microsoft believes to be an excellent predictor with respect to the possible failure of a project;
They did make an important remark with regards to the MS Project integration: currently there is no integration with MS Project Server but you can do this yourself through the mpp files.

The second edition was the architect edition and we defined the architect’s problems space. Today’s connected systems are becoming more and more complex and an architect is often confronted with communication problems between architects and developers, and development and IT operations teams. In Team System two different types of architects are distinguished:

Software/Application Architects
Network/Infrastructure Architects.
Following activities available to an architect were discussed and illustrated:
Create Logical Datacenter Diagrams (LDD)
Create Application Diagrams (AD)
Compose application components into “systems”
Create trial deployment diagrams
o Validate AD against LDD
Generate deployment reports
Generate and implement application components (web services)
The long term view of these diagrams is that you should be able to auto-deploy your applications or make recommendations concerning your deployment, before you actually begin the installation of the application.
Team System will allow you to fail often, fail early. Team System will help a team to avoid last minute disputes with IT Operations when it comes to deploying your apps to their servers. This System Definition Model (SDM) provides a common language for describing all aspects of IT system, both the constraints and the settings.
In the following minutes the speakers explained the following designers that are included by the Distributed System Designers in Team System:
Logical Datacenter Designer (LDD)
Application Connection Designer (ACD)
System Designer
Deployment Designer
You can find the definitions of these designers in the Visual Studio 2005 Team System: Designing Distributed Systems for Deployment article on the MSDN website.
The next question on the agenda was: “has UML died with the arrival of the Domain Specific Languages”? The answer is obviously NO: while UML will help you describe how to build the code, DSL will help you with the description of the capabilities of the code.

The third edition was the edition for developers and as it was becoming a habit by then we defined the developer’s problems space. Developers face many problems but we focused on the following:

Developers are not writing quality code;
Inadequate source control system and practices;
No way to relate code changes to justification.
I had no problem agreeing with the abovementioned statements and was happy to know that many developers will be helped by the upcoming release of Team System. The speakers focused in on that by providing a list of activities (besides writing code) that a developer probably does and then continued by explaining what Team System features help him to do a better job:
Unit Testing: The unit testing facilities in Visual Studio 2005 are much more powerful and easier to use than NUnit and there is a much better integration with the code coverage tool, than there is between NUnit and NCover.
Static Analysis: This will test your code for common problems, best practices, naming guidelines, etc. The tools that are incorporated are PreFast for C and C++, and FxCop for .NET.
Source Control: The speakers focused on the integrated check-in capabilities and check-in policies.

The fourth edition was the edition for testers and as we defined the problem space where these Team System citizens live in:

Testing controls are not integrated;
There is no version control for tests;
There are no integrated communication mechanisms.
There are different testing types and Team System has an out of the box set of tools that help the tester perform following activities:
Unit testing and component testing, and code coverage: It is important to notice that the unit testing and component testing activities have a significant overlap with development activities and as such both developers and testers can take advantage of these tools.
Web testing: Tools that support functional web testing. These tests are created in following steps:
o Create a recorded test, which simply records the user’s keystrokes and the URLs of the pages visited.
o Browse your website until you are done
o Convert the recorded test into a coded web test and customize the test further.
Load testing: These tools allow you to test the behaviour of the Web site under load. You can you can use your Web Tests as the basis for load tests.
Test management: This can be done by means of work items; these are units of work assigned to members of your product team.
As the speakers indicated, Microsoft is not providing all the tools required by the tester role but has been actively encouraging third-party vendors to ensure their tools can integrate closely with the Testers edition, and as mentioned Beta 2 comes with an extensive Application Programming Interface (API).

As you will definitely realize there are more than 4 roles involved in the software development process, examples are: Business Analyst, GUI designer, etc. In the first version of Team System they will still be able to participate by:

Accessing the real-time reports on the portal;
Using Excel or Project to maintain work items;
Using Team Explorer or command-line utilities to view/edit project artifacts.
Team System is for the entire team, but not all members are equally supported. Although this may look like a serious shortcoming at first, please realize that this is a version 1 product and the product supports most of the members in ways you could only dream of a year ago.

This concludes my summary of the theoretical part of the presentation given by Richard and Steven, the following hours they went trough an end to end demonstration of the features that were discussed in the first part of the presentation. As the title said it was an introduction to team system and so far it was best I have seen.


Team System
09/20/2005 19:41:52 UTC  #  Comments [2] 
 Sunday, 07 August 2005

Testing Levels

In previous versions of Visual Studio, a tester had to resort to many different tool vendors for his testing equipment. The release of Microsoft Visual Studio 2005 Team System will mark an important milestone in testing land since it marks the recognition of the tester as a first class citizen in Visual Studio. It will provide testers with tools that support testing throughout the entire software development and maintenance lifecycles. Does this mean that every tool a tester ever dreamt of or even really needs is in Team System? No, but it’s a great start. In this post I’ll focus on the test levels that are defined in the “V” model and the Visual Studio 2005 and Team System features that support them. The “V” model has become an industry wide standard for visualizing the levels of tests. Figure 1 is an illustration of the “V” model.



I regularly notice that there is a lot of confusion on the what, how and when wile discussing these levels. Before we can start to define the different testing levels it’s probably wise to define what a unit and a component is:

Unit:
A unit is the smallest compilable component. It does not include any communicating components and it’s generally created by one programmer.
Component:
A unit is a component. The integration of one or more components is a component. The reason for "one or more" as contrasted to "Two or more" is to allow for components that call themselves recursively.

On the right-leg of the “V” model you’ll find these levels:
Unit Testing:
During unit-testing the developer should always make sure the unit is tested in isolation, and that it is the only possible point of failure. In unit testing communicating components and called components should be replaced with stubs, simulators, or trusted components. Calling components should be replaced with drivers or trusted super-components.
Component Testing:
During component testing the same scenarios are tested as during unit testing but all stubs and simulators are replaced with the real thing.
Integration Testing:
Integration testing identifies problems that occur when components are combined. Component A and B are two components for which A calls B. Figure 2 illustrates integration testing for Components A and B:
Test Suite A contains the component level tests of component A.
Test Suite B consits the component level tests of component B.
Tab are the tests in A’s suite that cause A to call B.
Tsab are the tests in B's suite for which it would be possible to replace the code that is written to test component B by a call from Component A as input for the tests.
When you combine the test suites Tsab and Tab you will have a set of component tests that you can use after you modify Component B. When you modify Component B or A, you will be able to verify that will still function correctly together.


System Testing:
In system testing the tester will verify if the developed system or subsystems still meet the requirements that were set in the functional and quality specifications.
Acceptance Testing:
In acceptance testing the user and system manager will verify if the developed system still meets the requirements that were set in the functional and quality specifications. This level of testing is done in an environment that simulates the operational environment in the greatest possible extent.
Release Testing:
Prior to a public release of a program you must ensure that all bugs that were intended to be fixed were actually fixed. In release testing following aspects will be verified:

A mixture of previously failed-and-fixed tests and tests that have always passed;

Virus checking of the final installation package. Too many cases of distribution of viruses have been reported to not take this additional precaution.
A comparison of all features actually working reliably with prepared documentation. It is crucial that the documentation reflects all design decisions made during development and testing.

There are many variations on these definitions and the “V” model, but the key point is that the abovementioned testing levels are formally defined. A wise man once said: “Even when laws have been written down, they ought not always to remain unaltered.” Despite the fact that we are not talking about laws here, you can always leave a comment when you have another understanding of these definitions.

Team System | Testing
08/07/2005 15:43:44 UTC  #  Comments [1] 
 Monday, 11 July 2005

SCM and Team System, a marriage made in heaven?

In a previous post I stated the goals of successful configuration management and as you undoubtedly realized they are not easily accomplished in the field.  Now I'll try to give you an insight on how Team System helps you to tame this untamable beast.

A good SCM process makes it possible for developers to work together on a project in an efficient manner, both as individuals and as members of a team.  A development team must constantly manage requirements, tasks, source code, bugs and reports.  Gathering each of these item types in the same tool strengthens the communication pathways of teams and software.

Based on the goals mentioned in the previous post on SCM I'll try to indicate how Team System helps you to accomplish them:

·   Configuration identification:  This is often reffered as the process of recognizing the baseline applicability to a set of configuration items. It refers both not only to source, but all documents that contribute to the baseline.  Examples are:
·   All code files
·   Compilers
·   Compile / build scripts
·   Installation and configuration files
·   Inspection lists
·   Design documents
·   Test reports
·   Manuals
·   System configurations (e.g. version of compiler used)
Team System provides this capability through the concept of Work Item Tracking. A work item can define any unit of information that is part of the software development lifecycle. It can be any of the abovementioned Configuration Items. A powerful feature of Team System is that you can link work items to other artifacts, this allows your developers and manager to track which changes are related to which requirements, bugs.

·   Configuration Control:  Refers to the policy, rules, procedures, information, activities, roles, authorization levels, and states relating to the creation, updates, approvals, tracking and archiving of items involved with the implementation of a change request.
With Team System policies can be created and enabled inside Visual Studio that will enforce following standard check-in conditions, as well as others:
·   Clean Build: The project must compile without errors before check-in.
·   Statis Analyses:  Static analyses must be run before check-in
·   Testing Policy: Smoke-tests, unit-tests must be run before check-in
·   Work Items: On ore more work items must be associated with the check in.
You can also configure Team System to trak additional check in notes.  The standard notes in MSF Agile are: Security Reviewer, Code Reviewer and Performance Reviewer.  As with the most part of Team System, this is again fully custumizable.
Roles and authorization levels are covered by Team System Security.  By locking down privileged operations to only a few members, you can ensure that the roles within your team are always enforced.  You can for example specify which team members can administer, start or resume a build and so much more.

·   Status accounting: Recording and reporting the status of components and change requests and gathering vital statistics about components in the product.
Team System is hosted on SQL Server 2005 and its built-in reporting capabilities. As many as 50 pre-built reports are expected to ship with the release of Team System. These will include reports on: Project health, code churn, test pass, test coverage, active bugs,... These reports are directly available from the Reporting Services report manager portal or can be viewed on the project portal.

·   Configuration verification and audit: Verify that a product’s requirements have been met and the product design that meets those requirements has been accurately documented before a product configuration is released.Before acceptance into the live environment, new Releases, builds, equipment and standards should be verified against the contracted or specified requirements.
This is where the Dynamic Systems Initiative (DSI) comes into play.  DSI is a way to design for deployment or to put it in another way to design for operations. Key features of DSI are:
·   The visualization of systems and services
·   tracking of each system or service to properly describe it to another system or service.
It will in other words allow solution architect's to validate their design against an infrastructure architects's datacenter design and visa versa.  The first Microsoft implementation of DSI will be called the System Definition Model (SDM).  SDM describes your application and its deployment environment in layers.  The following layers are defined:
·   Application
·   Application Hosting
·   Logical Machines and Network Topology
·   Hardware
Microsoft will furter expand on their Dynamic Systems Initiative and will utilize the SDM model in Systems Managment Server(SMS) and Microsoft Operations Manager(MOM).

·   Build management:  Manage the processes and tools that are used to create a repeatable and automatic build.
Team System's Team Build provides an out-of-the-box solution to meet following requirements:
·   Get source code files for the build from the source code repository
·   Run static code analysis
·   Compile sources
·   Run unit tests
·   Save code churn, code coverage and other build information
·   Copy the binaries to a predefined location
·   Generate reports
The build automation tool in Team System provides you with an out-of-the box solution to meet these requirements.  The wizard helps you create an automated build script. Since the execution engine of Team Build is MSBuild, you can customize the process and accomplish any number of custom tasks.

·  

Process management:  Enforces consistent processes and promotes user accountability across the application life cycle, resulting in communication and productivity improvements enterprise-wide.
Team System will include two Microsoft Solution Framework(MSF) methodologies:  

·   MSF for Agile Software Development
·   MSF for CMMI improvement
While in MSF Agile it is more important to respond to change than to follow a plan, it is my understanding that MSF for CMMI process improvement is the only MSF methodology that fully provides process management support.  It is an excellent process to use on your project if your company is looking to achieve a measured, baseline competency in software development.  In short it will bring the process management side of the application lifecycle to your company and project.

·   Teamwork:  Controlling the work and interactions between multiple developers on a product.
One of the great advantages of the fact that Team System is such a highly integrated environment, is that it can instantly improve the communication on your team. All members of a team need to be in sync, watching their managers and need to work together to get their assignments done in time. Managers can always consult what the state of the project is, how much code churn is in the nightly builds, when the project has reached zero bugs,... Your team must constantly manage the same requirements, tasks, source, code bugs and reports. Because of the ways these are integrated in Team System it will automatically strengthen the communication pathways of your team and software.

I hope that by now you will agree that Team System is the new do-it all tool in the SCM's toolbox.  Team System is not a methodology or process but it integrates very well with the MSF methodology. Team System integrates most of the current tools that a Software Configuration Manager has dreamt about.  Microsoft will provide third party tool providers and yourself with an SDK that allows you to take advantage of common functionality that Team System provides.  Well, I cannot imagine a SCM that is not eagerly anticipating the release of Visual Studio 2005 Team System, but only time will tell.


SCM | Team System
07/11/2005 20:47:44 UTC  #  Comments [2]