TEAM FOUNDATION SERVER OVERVIEW

Visual Studio Team System (VSTS) integrates in one place a set of tools that enable a team to collaborate and coordinate their efforts on building and completing an application.

A team project is stored on Team Foundation Server (TFS) and has a name everyone on the team can easily identify.


TFS Architecture

Logical Architecture
TFS is a structured as a multi-layered application, consisting of a client layer, a business or application layer and data layer.






Data is stored in a MS-SQL server 2005 database. TFS creates a number of databases and tables for maintaining users, work items, source control and other resources.

The Application layer consists in a set of services which are available over the network. Most of these services are configured as web services which makes them accessible over the Internet.

Physical Architecture

It is recommended that for any installation, the data tier and the application tier are on different servers to meet the scalability and reliability requirements. Nevertheless, it is possible to have them in the same tier for installations which do not demand high scalability.

It is recommended to have a separate build server since the build activity is very highly CPU intensive. Keeping the main TFS and build server on same machine with frequent builds may undermine the performance of TFS adversely.

TFS supports the development of projects for teams that are working locally as well as for teams which are geographically scattered and connected remotely. To do that it uses proxies.

The following figure shows the standard physical architecture of TFS.



Services Offered by TFS

The main goal of TFS is to improve collaboration between multiple users in a development team. To do that it provides the following services:


Source Code Control (SCC)

SCC is the source control system of TFS. It includes operations such as versioning, Branching, Merging, Shelving, Un-shelving, etc. The source control is maintained in a SQL Server 2005 database. It allows multiple check-outs, placing locks on files, check-in policies which makes team members to execute certain actions when they are checking in source code.

Typically Team Foundation version control is used for source files but it is possible to add non-source files such as important project documentation.

Project Portal

Each team project has an associated project portal that is a Windows SharePoint Web site. Team members can use the project portal to store documents, find reports, and use other collaborative features.

Team Explorer
All team members work with team projects by using Team Explorer in the Visual Studio IDE. Team Explorer connects to one Team Foundation Server and displays team projects from that server. By using Team Explorer, every team member can find and update work items, view reports, manage documents, and work with product builds.

Alerts
Team Foundation provides alerts that are sent to you through e-mail when something changes on the team project. Alerts can be sent when the status of a work item changes, a check-in occurs, a build is completed, or when a build status changes.


Work Item Tracking

Team Foundation uses the concept of a work item to track fundamental pieces of work on a team project. Various types of work items are available and are based on the type of work that they represent.
Work item queries are used to find work items that match a specific set of criteria. Queries are useful to find the current status on work items.
All work items have a running history that logs all activity. Whenever a work item changes, whether the item's status changes to closed or notes are updated with new information, all the changes are logged so that anyone can review the complete history of activity on a work item at any time.

Microsoft Project and Excel Integration

Work items are stored in a database on the Team Foundation server; however, copies of work items can be imported and tracked in Microsoft Project or Microsoft Excel. For example, task work items can be imported into Microsoft Project and organized to load balance work for team members. Also, bug work items can be imported into Microsoft Excel to create a list of top priority bugs that must be fixed.

Building Automation

Each developer compiles the application in its workspace on the local machine. After compilation, the code is checked in the source code control. The checked in code has to be built to ensure its interoperability with code created at other time, maybe, by some other developers. This build process should be carried out periodically to ensure integrity of all the checked in code. TFS allows creation of build at pre-determined time using a component called Team Build. Team build schedules the build script created using MS-Build to be executed at the predetermined time.

Reporting

Reports are stored in a database on the Team Foundation server, and they track status and trend information over time on a team project. The data for the reports is stored in a data warehouse and collected from the operational databases on Team Foundation server. Types of information that can be tracked in reports are work item changes, check-ins, status on product builds, and test results. Also, cross-project reports can compare historical data for multiple projects.

Roles
Roles are assumed by one or more team members on a team project, and each role represents one or more disciplines that are required to successfully complete the team project.
Roles do not represent a one-to-one relationship with job titles or disciplines.

The Help documentation organizes content into three general roles: Administrators, Project Leads, and Project Members. These general roles are used by the Help documentation to help you find the tasks and information that most likely apply to you when you work on a team project.

Security Groups

Team Foundation security groups enforce permissions available for each team member. When a new team project starts, the administrator maps process roles for that team project to specific security groups and permissions. Additionally, the process template defines a default set of security groups.

Tool Integration

Team Foundation tools integrate with each other to automate many tasks that typically do not occur between tools. For example, when you check in source code to fix a bug, you can automatically resolve the work item that describes the bug.
Many Team Foundation tools are integrated with the Visual Studio. Team Explorer is the main window to work with team projects. Additional windows are available from Team Explorer such as Source Control Explorer, and the Build Explorer.

Team Foundation can also be extended to integrate additional tools that are created by third-party organizations.

Team Foundation can be used with older Visual Studio projects.

Customisation
Team Foundation supports customization of work items, work item instances, reports, security, project portal, documents and templates, source control settings, and process guidance content.

using the Logging Access Application Block (DAAB) in Enterprise Library

We can log info to: event log, email,DB,msg queue, text file, WMI event or to a custom location.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.EnterpriseLibrary.Common;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.ObjectBuilder;
...

LogEntry log = new LogEntry();
log.EventId=111;
log.Message = "Sample Log Message";
log.Categories.Add("Trace");
Logger.Write(log);

using the Data Access Application Block (DAAB) in Enterprise Library

a) selecting all the columns
Database db = DatabaseFactory.CreateDataBase();
string sqlQuery = "SELECT * FROM EMPLOYEES";
IDataReader reader = db.ExecuteReader(CommandType.Text, sqlQuery);

b) Passing a parameter
Database db = DatabaseFactory.CreateDataBase();
string sqlQuery = "SELECT * FROM EMPLOYEES WHERE CategoryId =@CategoryId";
DBCommandWrapper command = db.GetSqlCommandWrapper(sqlQuery);
command.AddInParameter("@CategoryId",DbType.Int32.categoryId);
IDataReader reader = db.ExecuteReader(CommandType.Text, sqlQuery);

c) Using Stored procedures
Database db = DatabaseFactory.CreateDataBase();
//specify params for the stored procedure
IDataReader reader = db.ExecuteReader("sprocname", paramvalue1, paramValue2,....);

ExecuteReader returns a DataReader (forward only cursor)
ExecuteDataSet returns a DataSet
ExecuteScalar returns a scalar
ExecuteNonQuery doesn't return a value

JSON (javaScript Object Notation) strings

It is another standard used to format data.
For instance here we have an XML notation:

<skills>
<web>
<skill>
<name>html</name>
<years>5</years>
</skill>
<skill>
<name>css</name>
<years>4</years>
</skill>
</web>
</skills>

This would be the equivalent in JSON:

{"skills":
{"web":
[
{"name":"html","years":"5"}
{"name":"css" ,"years":"4"}
]
}
}


Normally we will have a program that will build the JSON strings and another that will parse them.
.NET provides a set of classes that allow to build and parse JSON strings in the same way that we have also classes to do the same for XML files.
One of them is Jayrock.

Lambda expressions

c# 1.0 and 1.1

public MyForm()
{
listBox = new ListBox(...);
textBox = new TextBox(...);
addButton = new Button(...);
addButton.Click += new EventHandler(AddClick);
}
void AddClick(object sender, EventArgs e)
{
listBox.Items.Add(textBox.Text);
}

In c# 2.0

public MyForm()
{
listBox = new ListBox(...);
textBox = new TextBox(...);
addButton = new Button(...);
addButton.Click += delegate
{
listBox.Items.Add(textBox.Text);
};

you don't have to explicitly declare a new method to link it with an event.
Another alternative is to use anonymous methods.

(int x) => x + 1 // explicitly typed parameter (i.e parameter specified)
(y,z) => return y * z; // implicitly typed parameter (i.e. parameter type inferred from the context)

Aspect Oriented Programming (AOP) with Windsor Castle

Imagine that we have a class called Employee. This class might have a method called Save(), which saves a new employee record into the database.This method will have calls to the database and imagine as well that we log all new employees somewhere.

In terms of Aspect Oriented Programming in this method we have the Main Concern code (the code that saves the record employee into the database) and the Cross Cutting code, which is the code that is inside our method but that actually is not part of the main purpose of our code. In this case is all the code that performs the logging, but the same problem would exist in case of transactions, security or when invoking other functionality such could be a method in our application that performs an action (such as printing).

This mix of Main concern and Cross cutting concern results normally in a tangled code. Aspect Oriented programming pretends to give solutions to untangle this code.

Normally some languages provide solutions at compilation level, but unfortunately the .NET compiler is not AOP compliant. A solution could be to implement our code using attributes, but this also has its limitations. Another alternative is using Windsor castle.

Castle provides an interface called IInterceptor:

public interface IInterceptor
{
void Intercept(IInvocation invocation);
}

Then in our instance the class that performs the logging should be implement this interface:

public class Logger:IInterceptor
{
public void Intercept(IInvocation innvocation)
{
Logger.Write("Method:" + innvocation.Method.Name + " user:" + thread.CurrentPrincipal.identity.Name);
Innvocation.Proceed();
}
}

Then by providing a configuration file we would instruct the program to invoke the Logger everytime we Save the employee in our database without needing to specify anything in the code. So everything is done behind the scenes.

In our case the employee class that exposes the save method would look simply like this:

public class Employee:IEmployee
{
public void save(Employee employee) { //inserts record into the DB and invokes Logger behind the scenes}
}

So in our case we would have a config file that would look something like this:

<component id="Logger" service="<namespace of Logger>,<assembly of Logger>" type="<namespace of Logger>,<assembly of Logger>" />
<component id="Employee" service="<namespace of Employee>,<assembly of Employee>" type="<namespace of Employee>,<assembly of Employee>">
<interceptors>
<interceptor>${Logger}</interceptor>
</interceptors>
</component>


If instead of logging we would like to perform a transaction then we could do something like this:

public class Transaction: IInterceptor
{
public void Intercept(IInvocation invocation)
{
using (Transactionscope scope = new TransactionScope())
{
//do something
invocation.Proceed();
}
}
}

Aspect Oriented Programming (AOP) with Windsor Castle

Imagine that we have a class called Employee. This class might have a method called Save(), which saves a new employee record into the database.This method will have calls to the database and imagine as well that we log all new employees somewhere.

In terms of Aspect Oriented Programming in this method we have the Main Concern code (the code that saves the record employee into the database) and the Cross Cutting code, which is the code that is inside our method but that actually is not part of the main purpose of our code. In this case is all the code that performs the logging, but the same problem would exist in case of transactions, security or when invoking other functionality such could be a method in our application that performs an action (such as printing).

This mix of Main concern and Cross cutting concern results normally in a tangled code. Aspect Oriented programming pretends to give solutions to untangle this code.

Normally some languages provide solutions at compilation level, but unfortunately the .NET compiler is not AOP compliant. A solution could be to implement our code using attributes, but this also has its limitations. Another alternative is using Windsor castle.

Castle provides an interface called IInterceptor:

public interface IInterceptor
{
void Intercept(IInvocation invocation);
}

Then in our instance the class that performs the logging should be implement this interface:

public class Logger:IInterceptor
{
public void Intercept(IInvocation innvocation)
{
Logger.Write("Method:" + innvocation.Method.Name + " user:" + thread.CurrentPrincipal.identity.Name);
Innvocation.Proceed();
}
}

Then by providing a configuration file we would instruct the program to invoke the Logger everytime we Save the employee in our database without needing to specify anything in the code. So everything is done behind the scenes.

In our case the employee class that exposes the save method would look simply like this:

public class Employee:IEmployee
{
public void save(Employee employee) { //inserts record into the DB and invokes Logger behind the scenes}
}

So in our case we would have a config file that would look something like this:

," type="," />
," type=",">

${Logger}




If instead of logging we would like to perform a transaction then we could do something like this:

public class Transaction: IInterceptor
{
public void Intercept(IInvocation invocation)
{
using (Transactionscope scope = new TransactionScope())
{
//do something
invocation.Proceed();
}
}
}