You are currently browsing the category archive for the ‘Team Foundation Server’ category.

Whilst watching the VSTS 2010 Team Build Video by Jim Lamb when he was demonstrating the ability to configure what to delete when a build is deleted as part of the retention policy.

image 

From the above screen shoot it looks like they haven’t made any changes to the how the retention policy works.   As I was watching this it reminded me of the fact that you cannot use build quality as a trigger for the retention policies.

Now as I was a significant contributor to TFS Deployer any changes to the retention policy always sparks my interest.   To perform the deployment TFS Deployer uses changes to the build quality to indicate quick deploy applications from one environment to another.    What would be nice is for the retention policy to also be triggered off the build quality.  This would allow you to then retain all builds that have a “production” build quality, or the last 10 builds that have been “released to test”.

Anyway, I’ll keep my eye out for other changes in this area.

Advertisements

The team has been doing some great work around Team Build and have made some significant changes to the way that it works.    While watching the Channel 9 Video from Jim Lamb I grabbed some screen shots of the improvements.   There are many more so I would recommend that you watch the video.

Here they are:

New Build Summary Screen

image

 

Activity Log View of Build Summary

image 

Broken Builds View on Build Summary Screen

This one is really interesting,  What you can do is double click on the error and if it is a compile error it will bring up the version of the file that was build and allow you to fix the error and check it back in again.

image

Brian Harry has given us a teaser for the next Power Tools 2008 features.  The one I like the most is the Windows Shell Extension that is now making TFS just like Tortise SVN.  This feature will allow you to access TFS from within Window Explorer without having to spin up Team explorer.  Very Very nice.

  image_20

 

From: bharry’s WebLog : Preview of the next TFS Power Tools release

One of the benefit that you get when working for a company like Readify is you are given time to spend brushing up on the latest technology.   With all of the new Visual Studio 2010 video’s that Brian Keller has producing over the last week has been great to be able to spend a couple of days getting into them.     I must say that I have been impressed with some of the new features.   One that has caught my eye so far is the Dashboard that they are planning for the portal.  Whilst watching the Requirements Management and Traceability screen cast I grab the following pictures to give you an insight into what the new portal is going to look like.

 

image

image

I’m just loving the new features of the VS 2008 Team Explorer.    Our TFS server had to go down for maintenance tonight.  (The truth is that Mitch was playing with hard disks again 🙂  However, I still need to do work.   Well with the new features of the VS 2008 Team Explorer it first prompted me with a message say something like you are experiences troubles connecting to your TFS server would you like to go offline?   One click of the button and you are offline and working away.

The better things is when you want to go online.  All you do is go to the Source Control menu (under the file menu)and select go online.   After a bit of thinking you are displayed a box that looks like this:

image

This then allows you to see the changes that you have made offline and decided what you want to do with them.   Click on Go Online and you are away.  What ever the action is displayed in the “change” column is then applied to your project. This means that the files are automatically added, checked-out, deleted, renamed etc.  It is really a seamless experience!

I was reading through my feeds today and I noticed one from Tiago Pascoal that sparked my interest.   One of the most common questions that I get when consulting around TFS is how to restrict the list of people that you can assign a work item to.    After reading his post, I liked what I saw.   By making a slight modification to the process template (see below) you can restrict the list of people that are in the list.  

As part of my default installation I normally setup AD groups and assign them to Project\Contributers and Project\Project Administrators.   Doing this allows the infrastructure people to use their normal group management tools to manage the access to TFS.   I need to do some investigation to see if making this change to the process template will still work if named accounts are not in the Contributors group.

From Tiago’s post.

But i prefer a more restrictive view. Only list users that have access to the project. So when customizing process templates, I typically use this definition for the assigned to field:

<FIELD name="Assigned To" refname="System.AssignedTo" type="String">   
       <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">            
          <LISTITEM value="[Project]\Contributors" />       
          <LISTITEM value="[Project]\Project Administrators" /> 
      </ALLOWEDVALUES>       
      <PROHIBITEDVALUES expanditems="true">   
         <LISTITEM value="tfsservice" /> 
      </PROHIBITEDVALUES> 
      <ALLOWEXISTINGVALUE /> 
</FIELD> 

This definitions, states that only users who are contributors or project administrator of the project will be listed. (will exclude the tfsservice account from the listing. tfsservice being the account name that runs the service. By default Microsoft recommends tfsservice name, but your installation may vary). I also use the allowexisting value to allow us to edit work items assigned to users who no longer have access to the project.

In today’s modern development environment where clients are demanding higher quality products in shorter timeframes it is imperative that organizations find ways to deliver higher quality products in a shorter time period. An area in development that has traditionally taken a long time to complete is integration. In the past integration has always been a difficult time when two parties are trying to get their code to talk to each other. To help solve this challenging issue the industry has come up with some tools and techniques to make integration a relatively painless issue. Some of these techniques are as follows:

  • Continuous Integration
  • Dependency Replication
  • Automated Unit Testing and Code Coverage
  • Automated Deployment
  • Build Verification Tests
  • Deployment Verification Tests

In this post I explain how to setup up some of these concepts using Team Foundation Server as the backbone.

Explanation of Key Concepts

Continuous Integration(CI)

Continuous Integration is the concept of monitoring a section source code control repository for changes and once they have been detected starting off a build. Pictorially a continuous integration looks like:

image03

For modern development projects the CI build becomes its heartbeat. If the build is broken then there is something wrong with the project and it should be the first the first priority of all developers to ensure that the build is fixed. A continually broken build is a sign of a development team that is heading towards chaos. Normally, as part of a CI build you would also run automated unit tests to verify the build .

Dependency Replication

Dependency Replication is the ability to automatically copy (replicate) one or more outputs (dependency) of a successful build of one project to all of the other projects that utilize that output. This ensure that all projects that require on that component automatically have the latest version of that particular component. Pictorially dependency replication looks like:

image09

Automated Unit Testing

Unit testing is a procedure used to validate a particular module of source code is working properly from one modification to the next.[1] Automated unit testing take this process one step further and requires that the unit test are developed in a way in which they can be run by a build process. When combined with a continuous integration build, automated unit test help identify where or not a particular check in by a developer has caused other parts of the system to break.

Code Coverage

Code coverage is a mechanism that can be used to understand how much of the source code has been test. It is normally measure in a percentage of the source code exercised with a higher number being better. Code coverage is a useful tool to inform how much code has been exercised by a suite of unit tests. However, by itself it doesn’t provided any information on whether or not the program does what it is specified to do. It should also be noted that 100% code coverage does not mean that all possible scenarios have been tested.

Automatic Deployment

Automatic deployment is the process of releasing software without human intervention based on some event. With TFS the trigger that cause the automatic deployment is the changing of the build quality[2]. Normally as part of the automatic release you would run your build verification and deployment verification tests. . Pictorially dependency replication looks like:

image012

Build and Deployment Verification Tests

Build and deployment verification tests are similar types of tests. Firstly, build verification tests are a suite of automated tests that are run after you have successfully deployed and application into a test environment to validate the stability and quality of a build. They are different to unit tests in that they are typically long running functional tests that is testing an application from a holistic point of view rather than just at a component or unit level. Deployment Verification tests are similar to build verification tests except they are design to verify that the application and all of its required components have been correctly installed. They are also useful when troubleshooting issues such as communication failures and incorrect configuration settings.

Overview of Current situation

Currently we have already implemented Continuous Integration, Dependency Replication, Automated Unit Tests, Code Coverage and automatic deployment. To help achieve this things the following technologies the following components:

At a high level the current build and release process looks like:

image016

Solution Architecture

Development Environment Setup

The development environment has been arranged in the following manner:

image021


Source code Organisation

Within Team Foundation Server, there is a concept called a Team Project. A Team Project allows a project team to group everything related to a project under a single umbrella. Underneath a team project the source code can be arranged however a team likes. However, it is recommended to keep the structure of your source code repository quite flat. For example:

image024

The reason that I separate setup projects from the source code is to ensure that only files that should be released can be included into the setup project also as I normally use WIX as my setup project they require modification of the team build project. For reference, the TeamBuildTypes directory is an inbuilt directory that is maintained by TFS and is where all of the Team Build project files are stored.


Continuous Integration Configuration

Normally I setup one Continuous Integration Team Build Type per solution. Using the above source tree as an example, I would create the following CI Team Build Types

BuildType  Purpose
Solution1Continuous CI team build type for Solution1. Each time a file is checked into the path $/TeamProject/Solution1 this build is started. All of the Unit tests for Solution1 are run as part of this build.
Solution1Setup CI build project for the Setup Program for Solution1. $/TeamProject/Solution1Setup this build is started.

Dependency Replication

One of the other critical components when designing a source code control structure is how to manage project dependencies. To ensure that a solution is independent and can built it is own right it is important to stored all of the solutions dependent dll’s etc together with the solution.

The way that I normally achieve this is to introduce another folder called Dependencies under each of the solution directories. Into that folder all dll’s and other files that the solution is dependent upon are placed:

From a source code tree point of view it looks like:

image027

I then normal use the dependency replication of TFS Integrator to manage the dependencies between solutions in the same team project.

Another useful thing that I normally draw out is a diagram depicting the dependency tree for a team project for example:

image028

This allows you to very quickly and easily to view what your applications dependencies are. As an aside, one of the nice to have features for TFS Integrator that I have been thinking about is a front end that allows you to view the dependencies based on the information defined in the dependencyreplication.xml file.

From the point of view of TFS Integrator the dependencies are managed as follows:

image032

For details on what is replicated look at the DependencyReplication.xml file in the C:\Program Files\TfsIntegrator directory on the server where TFSIntegrator is running.

Release Process

One of the things that I try and achieve is to always ensure that the CI build process completes in the shortest period of time. Developers love quick feedback. There are always tasks that you are need to package a project up for release, that normally don’t need to be done as part of a CI build. Examples are:

  • Backing up the Database
  • Creating the Setup Program
  • Zipping up all the source code
  • Removing unnecessary files
  • Creating Release Notes

Normally, what I do is create a project called <TeamProject>NightlyBuild. So that these tasks can be completed easily and in automated manner.

I then normal use a feature in TFS called Build Quality to manage what builds I have released. At a high level my process looks like:

image035


[1] Source: http://en.wikipedia.org/wiki/Unit_testing

[2] Build Quality is a feature in TFS which allows you to place against any build the state of that particular build. This allows you to manage where in your application lifecycle at what stage a particular build is at. An example of build quality would be “Ready for Initial Test” to indicate that build is ready for testing or “Released” to indicate that build has been released.

About

I am a MCTS in Team Foundation Server based in Canberra, Australia. My passion is to improve developer productivity using tools like TFS.

I'm currently employed as a Senior Consultant at Readify

Tools I have Developed

  • TFS Integrator
  • TFS Deployer
  • TFS Listener

del.icio.us