Creating a yaml CI Build for .net application

One of the great announcements from this year's Microsoft Connect() conference was YAML support for VSTS build definitions. 

For me, it's a great way forward towards "codifying" the build pipeline. The current TFS builds technology, introduced in Team Foundation Server 2015, despite all the benefits of a loose and extensible mechanism is rather difficult to maintain as code and doesn't really fit "pipeline as a code" definition. If you remember, earlier versions of Team Foundation Server (TFS 2005 and TFS 2008) used an MSBuild file to run builds. Whilst this was easy to code and maintain, extensibility was rather limited. Then, Team Foundation Server 2010 introduced XAML builds with better support for workflows but was difficult to work with. TFS 2015 simplifies XAML but the whole logic is spread across different aspects of the build. Yaml solves this shortcoming nicely.

Enable YAML Builds Preview Feature

At the time of writing this post, support for YAML builds is still in preview in VSTS. To enable it for your account, click on your profile and select option "Preview Features" from the drop down menu

Select option "from this account [projectName]". Scroll down till you find the "Build Yaml definitions" feature and set it to On

We are now ready to use YAML builds.

Creating a Yaml Build 

There are two ways in which we can set up a Yaml build. 

1) Create a file called .vsts-ci.yaml. When you push your change with this file to TFS, a build definition, using this file is created for you.

2) Explicitly create a build definition using the YAML template, providing the path of YAML file that you have committed in the repo.

We will go with option 2.

Create build.yml file

YAML file format is the format of choice for configuration files and is used by some exciting technologies like docker, Ansible, etc. It's great that VSTS now supports it as well. 

For this demo, we are creating build for a simple .Net Web Application. For the purpose of building our application, we need to do the following

1) Restore all NuGet packages

2) Build the entire solution

Our very simple yaml file looks as below

steps:

- task: nugetrestore@1

displayName: NuGet Restore

inputs:

projects: "MyWebApplication.sln"

- task: MSBuild@1

displayName: Building solution

inputs:

command: build

projects: "MyWebApplication.sln"

The file is pretty much self descriptive. As you can see we we have two tasks. The first task uses nugetrestore passing the solution as input. The second task executes MSBuild passing the applicatino's solution.

Commit the file to your local Git Repo and push to commit to TFS.

Creating the Build definition

Now that our yaml file is committed, we will create a build definition to use it. To do this, click on the New button to create build definition. For the build template, select YAML and click Apply

We will then be asked to provide the build name, agent queue and path to Yaml file. Make sure, you have selected the correct repository and branch in the "Get Sources" option for the build definition.

Please note that YAML builds are only supported for Git are not supported when TFVC is used a version control repository.

Click on the Triggers tab to make sure that Continuous Integration is selected as option

Click save to save your build. Now this build is set up as a continuous integration build for your repository and is triggered with every commit.

Conclusion:

If you compare the amount of work you had to do to create yaml build, it's really a breeze as compare to TFSBuilds. There are many use cases of using YAML for your build definitions. You can set up a complete pipeline, decoratively executing each steps which can be developed and tested locally before being used in VSTS.

TFS 2017 Build - Partially succeed a build

At times, there is a need to explicitly set a Team build's result to be "Partially Successful". 

In Xaml, the way to forcibly build to set as partially successful is to set the build's "CompilationStatus" property to true and "TestStatus" to False, as shown below

<mtbwa:SetBuildProperties DisplayName="Set TestStatus to Failed so we get a PartiallySucceeded build" PropertiesToSet="TestStatus" TestStatus="[Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Failed]" />

Setting a TFS 2017 build to partially succeed is a bit more intuitive. Simply add a powershell task with an inline script and set the task's result to "SucceededWithIssues". Make sure it's the last task in your build, so that it doesn't affect the flow of task execution. The Powershell statement is shown below

Write-Host "##vso[task.complete result=SucceededWithIssues;]DONE"

My build looks as follow

Retention Policies for TFS 2017 Build System

TFS build system has had a major overhaul since TFS 2015. For people working on team builds since TFS 2010, there is some major learning curve. One of the things the people often find confusing is the retention policy in the new build system. In earlier versions of TFS, you could specify how many builds you want to retain for each status as shown in the screenshot below

Retention Policies for Xaml Builds

The retention policy is quite obvious and you have a deterministic number of builds retained at each status. It's not quite the case in the new build system. A sample retention policy in the new system looks like following

Retention Policies for TFS Builds

So what does it mean? 

Well, to say it simply, it means exactly what it says on the tin!! In the example above, the build would keep all builds from the last 4 days and keep a minimum of 20 builds. That is if there are less than 20 builds present for the given build definition, it would keep older builds until there are a minimum of 20 builds. Lets ignore the options with the lock sign, we will come back to it later. Note there is are no maximum count. It means that you can't control how many builds you keep for your build definition. This is a major shift from earlier retention policy where the number of builds kept for a build definition was deterministic. 

When are builds actually cleaned up?

If you are using an on-premise version of TFS (I am using TFS 2017 Update 2), the builds are actually not cleaned until 3:00 AM every day. For VSTS, it happens several times in a day but the time is not deterministic. The actually explains why there is only a "Minimum to Keep" option in the retention policy.

If you have a build definitions that is triggered very frequently, you will need to find a solution of actually deleting the build definitions. I will explain it in the next post.

What about Keep For 356 days, 100 good builds?

This is the option you see below your policy in the screenshot shown above. This is in fact a TFS Project Collection wide policy and enforces the maximum retention policy. So, in the example above, you can't set "Days to Keep" to more than 365 and "Minimum to Keep" to more than 100. In fact, if you have appropriate permissions, you can change it for the entire Team Project Collection.

TFS Project Collection Retention Policy

Multiple Policies

If you want, you can add retention multiple policies for your build definition. It is very useful, if you have build definition that builds different code branches (release branches for instance). You can use the retention policies to keep different number of builds from each branch. 

Multiple Policies

If you have multiple retention policies for the same branch, the retention would be the most lenient of all the retention, so whatever retains the most builds.

In the next blog post, I will show how we are keeping a lid on the number of builds for builds which are build very frequently, every couple of minutes in our case.

Extending Team Explorer in Visual Studio 2017

Visual studio extensibility has always been a great feature in Visual Studio and enhance the entire development experience. With Visual Studio 2017, there were a bunch of very substantial changes made with respect to extensibility. Most of these changes comes from the fact that Visual Studio now supports a lighter installation version with bare minimum feature installation as default. There is also the option to have multiple installation on the same machine. So, what does it mean for for extensions? 

VS2017 extensions now following the vsix v3 file format. If you have an extension for earlier visual studio versions and you want to port it to VS2017, it means a whole bunch of changes. Here, I am going to write an extension that demonstrate extending Team Explorer. We will create a very simple extension that has a button on Team Explorer, which will open notepad.

Project Creation & Dependencies

Let's start with creating a new extensibility vsix project. You will only see the option if you had selected the VS SDK option while installing visual studio. Let's call our project TeamExplorerExtSample. Visual Studio 2017 uses .Net Framework 4.6.1, so we select this version.

Once the project is created, you will see a couple of web files and a file called source.extension.vsixmanifest, which contains extension information. We will come to this file later.

Now let's add references to the assemblies we would need to extend Team Explorer. Note that with visual studio 2017, assemblies are not added to GAC so we would need to make sure that all desired assemblies are included in the vsix. To display a navigation button in team explorer, we would need to implement the interface ITeamExplorerNavigationItem2, so we would need to add references to the following assemblies

•     Microsoft.TeamFoundation.Controls
•     System
•     System.ComponentModel.Composition
•     System.Drawing

VSIX Manifest file:

The manifest file contains information about the extension, it's dependencies, assets and pre-requisites. Double click on the source.extension.vsixmanifest to see details. To extend Team Explorer, the key thing to remember is to add the assembly containing classes that implement Team Explorer interfaces as a MEF component. This will ensure that visual studio loads it up when loading team explorer.

Our VSIX manifest file looks like this

Extending ITeamNavigationItem2

Our extension will create a button in Team Explorer that opens up the notepad application. To do this, we need to extend the ITeamNavigationItem2 interface. The interface is found in Microsoft.TeamFoundation.Control assembly that we have already referenced. We will also need to add TeamExplorerNavigationItem attribute. Our very simple class looks as below.

namespace TeamExplorerExtSample

{

       using System;

       using System.ComponentModel;

       using System.Diagnostics;

       using System.Drawing;

       using Microsoft.TeamFoundation.Controls;

       [TeamExplorerNavigationItem("C9B2CF74-0C87-4CEA-ACA9-8CC1C816D7F3", 1800)]

       public class NotepadNavigationItem : ITeamExplorerNavigationItem2

       {

              public bool IsEnabled => true;

              public int ArgbColor => 0;

              public object Icon => null;

              public string Text => "Open Notepad";

              public Image Image => null;

              public bool IsVisible => true;

              public event PropertyChangedEventHandler PropertyChanged;

              public void Dispose()

              {

                     this.Dispose(true);

                     GC.SuppressFinalize(this);

              }

              protected virtual void Dispose(bool disposing)

              {

              }

              public void Execute()

              {

                     Process.Start("notepad.exe");

              }

              public void Invalidate()

              {

              }

       }

}

As you can see, the only matter we have got in the class is a call to Process.Start to start up notepad. The navigation item appears as below

Click on the button and a new instance of notepad opens up.

Conclusion:

Admittedly. this is a very simplistic extension but contains all the steps you need to extend Team Explorer. You can add classes to add Pages, Sections and Links in Team Explorer, add icons \ images and menu items. The code sample from post is here. 

Running a VSTS Build Agent on a Windows Container

In my previous blog post, I wrote about running a VSTS build agent on a docker container. So, it was only logical to try it out on a Windows Container. I had a few pitfalls in my quest to do that and found an issue on my way, however. it all worked in the end.

Note: 

At the time of writing this blog, running vsts agent is not supported on Windows Nano server. I could only manage to run it on microsoft\windowsservercore image. 

Window Server 2016 and Windows Containers

Windows Server 2016 comes with a full container support powered by built-in operating system features. There is a great session on the internals of windows container on channel9. There are two mechanisms of setting up containers on Windows - Hyper-V Containers which are effectively light weight virtual machines and Windows Containers. I am going to use Windows Containers

1. Windows 2016 Virtual Machine

To host my containers, I got a Windows 2016 virtual machine going. At the time of writing this blog, Windows Server 2016 is still at Technical Preview 2 stage and new updates are coming frequently. They can be downloaded from the Microsoft website. 

The minimum build you will require is Windows 2016 Server build 14393.

Once you have installed windows and are on the virtual machine, open command prompt and type in winver. You will see a dialog like this. Make sure the build number is at least the required version

2. Install Containers Feature

Type in the following command in a PowerShell console window

Install-WindowsFeatures Containers

The feature needs a restart so type in the following

Restart-Computer -Force

Once the machine is restarted, continue with following 

3. Install Docker

The docker version deployed from the msi isn't supported on Windows Server 2016 yet. For me downloading the docker msi from the docker website didn't work and I got the following error

However, got it working by downloading the following zip file 

https://download.docker.com/components/engine/windows-server/cs-1.12/docker.zip 

and extracting it to Program Files. I did it by running the following in my PowerShell console 

Invoke-WebRequest "https://download.docker.com/components/engine/windows-server/cs-1.12/docker.zip" -OutFile "$env:TEMP\docker.zip" -UseBasicParsing

You will have two executable files in the extracted directory as shown

Add the directory to your path variable. 

Now register the dockerd service by typing the following

dockerd.exe --register-service

Alternate Installation Option

After installing docker, I found that the following was a better and easier way of install docker on Windows Server 2016. Type in the following in your powershell console.

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force 

Install-Package -Name docker -ProviderName DockerMsftProvider

Restart-Computer -Force

Once installed, verify that docker is running fine your machine by type in the following 

docker run microsoft/sample-dotnet

You should see a message of the like "Welcome to .Net Core!" on your console window. This means that your docker instance is working fine.


4. Pulling microsoft/windowservercore image

So, this is where I got stuck a bit. I was trying to use microsoft/nanoserver, which is a fraction of a size of full windows image and support .Net Core. In the end, I found out that running vso agent on server on nano server is not supported yet.

So, I pulled the full server core image. You can do it by running

docker pull microsoft/windowsservercore

The image is about 8GB and takes some time to download. Once pull, run the image by typing in 

docker run microsoft/windowsservercore

At this stage, we are on a windows docker container running Windows 10. I checked in by typing [System.Environment]::OSVersion.Version and got the following version

Major  Minor  Build  Revision
-----  -----  -----  --------

10     0      14393  0


5. Running VSTS Agent

Now that we have a running container, the steps to run VSO Agent is as simple as running it on any Windows 10 machine. 

The only complication is the lack of GUI, so I used powershell to download zip file and extract it as follows

Invoke-WebRequest https://github.com/Microsoft/vsts-agent/releases/download/v2.108.0/vsts-agent-win7-x64-2.108.0.zip -outfile vsts-agent-win7-x64-2.108.0.zip

Expand-Archive -Path .\vsts-agent-win7-x64-2.108.0.zip -DestinationPath C:\vsts-agent 

You will see the usual vsts agent's files in the destination directory. Simply type in .\config.cmd and follow instructions.

Set up a VSTS Build Agent on a Docker Container

In my last blog post, I wrote about setting up .Net core on an Ubuntu 16.04 machine. In this post, I will go a step forward and explain how to set up a container to run as your build agent.

Containers are brilliant in that they provide a rather lightweight mechanism of setting up desired software in your build agent without installing it on host machine or in a virtual machine. In this post, I will explain setting up a Docker container on a Windows 10 machine, install all the desired software  for build agent and running a build to compile an ASP.net core application on it.

This post is split into following areas

• Setting up Docker on a Windows 10 machine
• Create a Docker image to run Build Agent.
• Configure and run a Build Agent on Docker.
• Run a Build on the newly setup Build Agent.

Set up a Docker container on a Windows 10 machine

Docker on windows uses Hyper-V to create a linux virtual machine, The Docker daemon is run on this virtual machine.This means that you need at least Windows 10 professional to run Docker. We are using Windows 10 Enterprise. 

To install Docker visit the site https://docs.docker.com/docker-for-windows/ and install the .MSI by clicking the "Get Docker for Windows (stable)" button. The installation will setup Docker for you, by setting up a VM called MobyLinxuVM. It would also add Docker's bin directory to your path, so that the Docker command is available in your command window.

Every docker deployment has a "hello-world" image. To test docker, type in

docker run -it hello-world

You should see the text "Hello from Docker!" in your response.

Create a Docker image to run Build Agent

Now that docker we have a Docker instance running, lets set up a Docker image with all the software needed to run a build agent. The VSO build agent is Node.js based so installing Node.js and it's pre-requisites is a requirement. Also, since the build agent is going to build .Net Core core, we would also be installing .Net core.

To start with, we get a Docker image with the latest version of Ubuntu. At the time of writing this post, the latest version available was 16.04. So we start with getting this version. To do this run

docker run Ubuntu:16.04.

It would look for the instance locally and if it's not found download it from Docker hub. Once the command is complete, the Docker Ubuntu 16.04 image will appear in your “docker images” command

We now install Node.js, npm and vso agent onto the image and store it as another image. To do that the first step is to run the Ubuntu:16.04 image as a container. To do that, run the following command.

docker run -t -i Ubuntu:16.04

You will now be on command prompt of root. To run the desire software, run the following commands one after another

apt-get update
apt-get install npm nodejs
apt-get install nodejs-legacy
npm install vsoagent-installer –g

My Ubuntu 16.04 instance didn't have https protocol installed, so installed it by running

apt-get install apt-transport--https

We will also need to install git on it

apt-get install git

Now, to install .Net Core run the following

sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list'

apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893
apt-get update

apt-get install dotnet-dev-1.0.0-preview2-003131

At this stage, the container contains all the software that you need to run a vso build agent.

Configure and run Build Agent

The only thing left to do now is to configure the build agent. The agent installer allows us to easily create multiple agents on a single server. Each agent will run inside its own folder. We create a folder called MyBuildAgent1 and uses it to run the agent. To do this run the following commands

mkdir MyBuildAgent1
cd MyBuildAgent1
vsoagent-installer

All commands so far has been run using the root user. We don't want to run the build agent to run as root, so will create a user called buildagentuser and switch to it to use it. Below are the command that you need to run.

adduser buildagentuser
chown -R buildagentuser /MyBuildAgent1

The build agent is almost ready to run. At this stage we want to commit this container to save the image. This way we can use it again.

Step out of Docker container by pressing CTRL+P followed by CTRL+Q. You will be back to command prompt. Now type in "docker ps" to view the list of containers running. You will see a response like following




Here, the ubuntu:16.04 running container has the Id "aea7e12541d5". We will commit this container to create a new image. To do this, type in the following on your command prompt

docker commit -a "Hamid Shahid" -m "Basic vso .net core build agent" aea7e12541d5 basicvsogent:v1

If you are following instructions, please use your container id. You can verify it by running "docker images". You will see the new image in the list of images



Since, we just "stepped out" of Docker container we were working now, we will now reattach it and run the build agent. To do this type in

docker attach aea7e12541d5

Now start the build agent by running

node agent/vsoagent

You will be prompted about your VSTS url and the credentials to connect to. I used the following options in the prompt



The user you specify must have the service "Service Account" role in the agent pool you specified. In my case, I had added them to the VSTS group "Agent Pool 1 Service Account Users".


.
Now that my build agent is now running, I will create now create a simple build definition to run the build. We had already created a simple .Net core Asp.net application.

Run a build on the new build agent

We will now create a very simple build definition and execute it on the new agent. Our build definition has three simple steps.

1) In the first step, invoke dotnet with the argument "restore".

2) In the second, invoke dotnet with the argument "build". Make sure, you set the working folder to the source directory

3) In the third step, set the contents to "**/*.dll".

Since, we used the Default Build Pool, set it to use the default build agent.  Now run the build and let's monitor the build agent command window. We should see messages regarding the statue of the build job.

This is so awesome. Now that we have the Docker image captured as well, we can start other build agents and distribute our build load across containers. This is far more efficient than running virtual machines as build agents.

The above would only work for dot net core applications. In my next post, I will write about how to set up VSTS agents on Windows Containers, where we would also have the ability to build .Net applications.

Shelveset Comparer now supports Visual Studio 2015

Last year, I created a visual studio extension that allow users to compare two shelvesets. The extension has proved to be quite popular. 

The visual studio 2015 version of the extension is out today and can be download from here. 

Please free free to use it and give your feedback.

Git For TFVC Users

One of the biggest features of Team Foundation Server 2013 is it’s support for Git. Git is popular source code repository specially in the open source community. However, unlike Team Foundation Version Control (TFVC), Git is a distributed version control system. This means that for regular users of TFVC, there are some conceptual differences to consider when working with Git. In this post, I will explain some of these differences and also illustrate the equivalent operations in Git for most common TFVC operations.

Centralized Vs Distributed Version Control Systems

TFVC is a centralized version control system while Git is a distributed. That is to say that at any point of time, the server in TFVC contains the “true” version of any file. Anyone making a change is expected to fetch this version, make the change and then check-in against this version. For this to happen, the client must be connected to the server. 

Git, meanwhile, is a Distributed Version Control system where each client machines keeps a local copy of the repository. Any user working with the client can keep working on local version of the file without talking to the server. It is only when the client tries to “push” the changes that a contact to the server is made. Since multiple people can work on the same file in their local repositories, there might be some conflicts. Git addresses this requiring the users to resolve all conflicts with the remote repository before they “push” their changes.

Here, I am “disregarding” local workspaces, which is a feature that was introduced in TFS 2012. Local workspaces has some similarities with Git in that it propones “Change –> Merge –> Push” way of working rather than “Checkout –> Change –> CheckIn”. However, the fact remains that TFVC is a centralised  system.

Changesets Vs Commits

All changes in TFS are checked in as changesets. A changeset is a single unit of change that can be checked in and constitutes the list files which are changed. A changeset can be reverted back and merged to different branches.

The equivalent in Git are commits. They are essentially the same as changesets except that they exist on local repositories. Once pushed to remote repository, they are essentially same as changesets in TFVC.

Until commits are pushed, they reside only on the local repositories and are not visible to other users who clones or fetches the remote repository. You can event amend your commits.

Branching

Branching in TFVC is a very different concept that branching in Git. In TFVC, branching is essentially a “deep copy” of the original branch. . The branching operation is time consuming and is always executed on the server. Once a new branch is created, users can work on it completely independently without needing to even get a local copy its parent. Each branch has its own version history.

In Git, a branch is light weight. In actual, it is merely creating a new head pointer to the version pointed by the parent branch. Once the new branch is created, the new head pointer is moved as new changes are committed. In essence, all branches exists within the same file path. The only difference between an active branch and inactive branches is the head pointer selected at the moment.

Merging

It can be safely stated that merging is one of the strongest feature in Git. TFVC perform merging using the 3-way merge algorithm, in which it attempts to merge the changes from baseline to the newer version and also the changes from the baseline with the version of the file in the current workspace. If it can’t resolve any conflicts it asks the users to resolve conflicts.
Git supports 3-way merge as well as a host of other merging algorithms such as recursive, octopus, etc. While it uses the optimum algorithm for the situation, user has the option to select the merge algorithm through the command line parameter as well.

Security

TFVC is fully integrated with Active Directory and uses it for security. Online version of TFS can use an authentication service such as windows live service to authenticate users. Moreover, there are options of set permissions for individual files, folders and branches.
Git does not have such an extensive security mechanism. Users can be restricted permission such as make them read-only on a repository but there is no support for setting permission for files and branches.

Common Operations

Since the working practices are quite different between Git and TFS version control, there isn’t a simple one to one mapping for quite a few operations but I will make an attempt with the following table.

Get Latest Version · Fetches the latest version of files from the TFS server to the client. · Operation can be performed for an entire team project and any folder beneath it. · There must be a local workspace present with mapping from server folder paths to local directory paths.	There can be three commands corresponding to the Get Latest Version in TFVC. clone · Creates a copy of the remote repository locally. · To be used when you need to get the contents of the remote repository for the first time. · Note the difference in terminology. It is a copy and not a fetch. In fact, if disk on the server gets corrupted, this can be copied to the server. · Repository has to be cloned in entirety. Cannot clone parts of the repository. Fetch · Used to get the contents of the remote repository. · To be used when there is already a local repository. · Doesn’t attempt to merge the changes from the remote repository to the local repository. Pull · Similar to “Fetch” except that it also attempts to merge the changes from remote repository on to the local repository.
Add To Source Control · Allow one or more files or folders to TFS server. The files are only marked for addition and will not be added until the changes are checked-in.	init and add · Initialize a new repository using the existing directory. · Once the directory is initialized, the files must be added using the add command. · Changes are not made permanent in the repository until there is a commit and are not sent to the server until there is a push.
Check Out · Enable user to change files locally. · TFS doesn’t fetch the latest version of the file but users should work with the latest version or they will get merge conflicts when they attempt to check-in. · The changes stay local on end user’s machine until the changes are checked-in.	branch and checkout · The checkout command in Git switches to the given branch in the local repository. · Occasionally, the user will require to create a branch before the checkout. · The branch command in in Git creates a new head to track the version. Creating a branch means that user can keep on working a completely separate version with the option to revert back to the version from which the branch was taken. (More on this later).
Check-In · Enable users to publish the changes made locally to the server. · The check-in command checks the version of the file that was taken as a baseline before changes were made locally. If there is a modified version available on the serve, user is required to merge.	commit and push · The commit command publishes the changes made by the user to local repository. Since, the change is only published to local repository, there is no equivalence in TFVC. · The push command publishes the changes made locally to the remote repository. · Like TFVC, if there are subsequent changes made on the remote repository, Git requires to merge the changes.
Shelve Changes · “Parks” the changes made locally on the server so that they can be fetched either by the same or another user.	· There is no equivalence of shelvesets in Git. The closest is the stash command which publish changes to the local repository. However, unlike shelvesets, these changes are not visible to server.
History · Displays the history of changes made to a particular branch, folder or file. · Some of the features such as annotation is supported by TFS Power tools.	log · Displays the list of commits for the currently active branch. Blame · Displays the revisions and the author of each revision for each line of the given file. Annotate · Annotates the given file.
Delete / Destroy · Deletes the given file or folder. · The destroy command permanent delete files and folders. · The deletion / destruction is only performed on the server after the deleted files are checked in.	rm and push · Removes the file from local repository. · Removal is published to the remote repository after the push operation. · There isn’t an equivalent of destroy command in Git. However, the reset HEAD command can be used to remove history of older version.

BuildStepDuration activity - TFS Build Extensions

The September 2013 release of TFS Build Extensions is available for download now. There are some cool new activities added to the library. Amongst them is the BuildStepDuration activity. It is a very simple to use activity that allows you to view a break down of build steps and the time each build step took in a completed build. This is really useful for build masters who are looking to optimise their build and are having a hard time in getting the information from Visual Studio build details window, which shows all information in a hierarchical way.

More information can be read from the activity documentation http://bit.ly/15VuILe.

The latest version of TFS Build Extensions can be downloaded from here.

Technorati Tags: Team Build,Team Foundation Server

Uploading files to an ftp site from your Team Build

The July release of TFS Build Extensions were released yesterday. Amongst other improvements and features there library not contains an FTP Activity that allows the team build to interact with an FTP. You can for instance upload the contents of your drop location to an Ftp Site. This blog post details how to do so.

To use the Ftp activity activity, simply drag and drop it on the build process template. Once dropped, set the appropriate values for the properties required and if all the information is correct, the activity will be able to do the required task on your ftp server. Regardless of the ftp action, the following two properties are required and must be set

• Action: Must be set to one possible values of FTPAction enumeration.
• Host: Must be set to the host name of the ftp site.

To illustrate the use of the activity, we take a a very simple scenario that all files produced by the team build should be uploaded to an ftp site. Moreover, we also require that the files of each build should be created in a separate directory.

To start with, we need to take drop a sequence activity at an appropriate location in the build template. I chose to do it just above the “Check In Gated Changes for CheckInShelveset Builds”.

The next step is to drop the activities to find files, create directory and upload files. My final “Upload Drop Files to Ftp” looks as follows

Note that in the workflow I am using the FindMatchingFile activity, which looks for all files in the drop location and put the result in a variable “DropFiles”,  of type IEnumarable<string>.
Next the workflow checks if there are any files in the drops folder, if there are it will
First create a directory on the FTP site using the Ftp activity with action “FtpAction.CreateDirectory” using the name of the build. The value of all properties for this activity are shown below

The last step is to upload all files. The workflow has another FTP activity with action set to “FtpAction.UploadFiles”, passing in the enumeration “DropFiles”. The value of all properties of this activity are shown below.

And that is it. At the end of the sequence execution everything in the root of drop folder will be uploaded to the Ftp site provided.

Running the Activity
When your run the build workflow, you should see the Ftp activity being executed and the files in the drop location being uploaded to the ftp directory.