TEAM FOUNDATION BUILD: BRIEF INTRO

Team Foundation Build is a build orchestrator, part of Microsoft Application Lifecycle Management suite. Tightly integrated with other Visual Studio Team System components such as version control, work-item tracking, testing and reporting.

Team Build is built on top of the Microsoft Build Engine (MSBuild). Team Build consists of the Team Build Service layered on top of the MSBuild build system. MSBuild is responsible for the build itself, while the Team Build Service is responsible for communicating with the TFS application-tier.

Features highlights:

• Facilitates out of box build process for most the of .NET applications
• 5 steps out of box end-end build process
  • Retrieve the code from Team Foundation Source Control
  • Compile, Run tests, static code analysis against compiled code
  • Release the builds onto a file server
  • Create/update work items appropriately
  • Publish the build reports
• Supports executing build on multiple build machines without any script changes
• Efficient retention policy to delete old builds
• Locking mechanism to keep the build forever
• Provides the capability for public and private or desktop builds
• Provides APIs for extension
• Ability to build projects/solutions in parallel fashion
• Beyond build process, other parts of software lifecycle like packaging, deploy could be integrated with Team Build

Refer the high level Architecture here

Team Foundation Build logical flow:

Build types, build creation, execution and viewing results are largely wizard driven and straight forward – let’s move on to the actual Build Process flow

List of customizable Team Build Targets – If you wish to extend, tailor Team Foundation Build according to your project needs

For full information on this specific topic – have a look at this

BeforeEndToEndIteration	BeforeCompileConfiguration
AfterEndToEndIteration	BeforeCompileSolution
BeforeInitializeWorkspace	AfterCompileSolution
AfterInitializeWorkspace	AfterCompileConfiguration
BuildNumberOverrideTarget	AfterCompile
BeforeClean	BeforeGetChangesetsAndUpdateWorkItems
AfterClean	AfterGetChangesetsAndUpdateWorkItems
BeforeGet	BeforeTest
AfterGet	BeforeTestConfiguration
BeforeLabel	AfterTestConfiguration
AfterLabel	AfterTest
BeforeCompile	BeforeDropBuild
AfterDropBuild	BeforeOnBuildBreak
BeforeCreateWorkItem	AfterOnBuildBreak
AfterCreateWorkItem	GenerateDocumentation

List of customizable Team Build Properties

Full information

CustomPropertiesForClean	LabelName
CustomPropertiesForBuild	OutDir
SkipClean	UpdateAssociatedWorkItemsOnBuildBreak
IncrementalGet	StopOnFirstFailure
IncrementalBuild	SkipGet
CleanCompilationOutputOnly	SkipLabel
SkipGetChangesetsUpdateWorkItems	SkipInitializeWorkspace
SolutionRoot	SkipInvalidConfigurations
BinariesRoot	SkipPostBuild
LabelComment	SkipDropBuild
CustomizablePublishDir	SkipWorkItemCreation
	CustomizableOutDir

Essential build management for modern day software development

Some of the items that we should be watchful inorder to make configuration & build management more productive and useful for the whole SDLC….
here are some common challenges and after effects if we ignore to take care of them….

Repeatability & reliability

Repeatability
-Is about being able to do the same thing over and over
-Is something repeatable after  say 6 months
-Do developers have the ability to pullout a code and assembly which is in live production today

Reliability
-Does the process produces correct and accurate results every time
-Are you confident that the code is being delivered into the build has the defect,  not the build/package/deploy process itself

Lack of ‘Repeatability & reliability’

Low defect fix rate
-Not able to repeat the build which is in production already..
-Do we have the ability to reconstruct the development environment with the PROD code, fix a defect and ship a patch quickly
-How long does it take to reconstruct matching code and assembly on a developer box? Should be in minutes…
-Inaccurate fixes

Nonstop issues with reliability of build execution
-When a defect found,  are you sure the problem is with the code or could it be the build process
Management lost confidence on build process

Traceability & completeness

Traceability
-Ways to understand the complete life cycle of  defect/feature that goes into a build….

Completeness
-Ability to trace it back completely and figure out whether the build contains all of what was intended…
-Does it add any value towards the program goals and objectives
- Why and What are we delivering in this build

Lack of ‘traceability and completeness’

–Not being able to say exactly what is in the build…. 
    ->what new features, enhancement, defects have been added and why?
 –Incomplete builds  & Missing builds 
    ->Missing some artifacts
    ->Post deploy manual hacks/changes on the environments beyond build process
    ->Sometimes builds are missing from the source control
–Not being able to say where the build is being used? 
   ->Where the build has been deployed? Is it being testing on different environments? What version do I have currently on different environments?
–Not being able to say how the build was carried out…. 
  ->Did the source got baselined?
  ->With or without third party assemblies? What version of 3rd party assemblies used?
  ->Was it environment specific build? Any configuration items change based on the environment?
  ->Were there any special compiler/packaging options, instructions followed?

Speed, Agility 

Speed
-Is about how quickly a developer can integrate defects and test his changes?
-How fast and integrated is the build process
-Is the process efficient & has absolutely essential steps
-Is it an unattended build/package and deploy process – if manual process is essential, that’s a big bottle neck

Agility
-Is about having the build/deploy process in which changes can be integrated
  ->quickly
  ->efficiently
  ->independently, as and when needed
 

Lack of ‘speed, agility’

Late integration, long builds…. late night firefighting…

–High possibility of incomplete build
– features/enhancements/defects may not meet the entry criteria
–Uncertain defect quality
–Possibility of ‘high defect re-open rates’
–Not being able to integrate changes quickly
-Does the build process take so long – results in weekly build rather than CI builds– what if that build fails
-Travelling with a hidden tiger until next build
–Deferred testing puts the milestone in risk
–Lack of confidence on scheduled build
– not sure what can/can’t go
–Risk of missing milestones in the wake of late integrated testing
–Risk of late night fire fighting towards the end of development cycle – team morale will go down 

So how can the process be improved?

Following high level goals could make you better
–Implement Continuous Integration
•Define a build once in 30-45 mins interval to make sure source code is syntatically correct and produces binary
–Write light weight tools to encourage teams working on Source Control every single minute
•Create some tools to quickly refresh source & assembly based on build number– improve developer productivity
–Envision efficient check in policy & make developer life easy
•like gated checkins to ensure a change is built along with the latest content from the source tree automatically prior to check in
–Automate and make unattended build/package/deploy/sanity testing
•Use best and authentic tools to ensue maximum benefits from automation
–Ensure build process is simple, transparent, fast and easy
•Anyone should be able to initiate and manage the build process with no or negligible training
-Try to adopt Application Life cycle Management model - Integrate tools suite right from Requirements thru testing..

PowerShell+update TFS build properties

If you are wondering how to update some build properties like ‘build quality’ or overwrite ‘retention policy’ or some other TFS Build property dynamically/scriptically…. PowerShell is a good option….

After I deploy the build on a test environment, I wanted to update ‘build quality’ and ‘lock’ a specific build for reference -  so that my retention policy doesn’t wipe off the build….. naturally Visual Studio Team Foundation Client provides a tiny ‘lock’ symbol and it does provide interface to manage build quality too…. they appear right on the build explorer window and are simply perfect….however, I tend to forget that operation post deploy – meaning the way I got my deploy is completely unattended……of course, my retention policy retains only 5 builds…its embarrassing  when a developer seeks a specific build inorder to  reproduce a defect…..

When  I was seeking ways to automate this task..certainly there are ways like MSBuild custom task etc…. but I hate to write c# code, compile, reference that in MSBuild …. PowerShell was an elegant and neat option for my need…. loads the assembly at runtime…. no compilation, msbuild etc….

So the following script can be used to set build properties automatically post deploy – simply call powershell.exe with appropriate parameters….

here we go..

#must pass inputs in the following order

#1. TFS Uri 2. project name 3. build definition 4.build number 5. build quality 6. retain(true,false)

param (

[string]$TfsServerUri = $args[0],

[string]$ProjectName = $args[1],

[string]$BuildDefinitionName = $args[2],

[string]$MyBuildNumber = $args[3],

[string]$MyQaluty = $args[4],

[bool] $retainBuild= $args[5]

)

$ErrorActionPreference = “Stop” ;

if ($Verbose) { $VerbosePreference = “Continue” ; }

Write-Verbose -Message “Loading TFS Build assembly…”

[void][System.Reflection.Assembly]::Load(“Microsoft.TeamFoundation.Build.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”)

Write-Verbose -Message “Loading TFS PowerShell snapin…”

$TfsSnapin = Get-PSSnapin -Name Microsoft.TeamFoundation.PowerShell -ErrorAction SilentlyContinue ;

if ($TfsSnapin -eq $null) {

Add-PSSnapin -Name Microsoft.TeamFoundation.PowerShell ;

}

Write-Verbose -Message “Getting TFS server instance…”

if ([string]::IsNullOrEmpty($TfsServerUri)) {

$TfsServer = Get-TfsServer -Path (Get-Location) ;

} else {

$TfsServer = Get-TfsServer -Name $TfsServerUri ;

}

Write-Verbose -Message “Querying builds…”

$BuildServer = $TfsServer.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer]) ;

$DetailSpec = $BuildServer.CreateBuildDetailSpec($ProjectName, $BuildDefinitionName) ;

$DetailSpec.QueryOrder=”FinishTimeDescending”;

$DetailSpec.MaxBuildsPerDefinition=10;

$Builds = $BuildServer.QueryBuilds($DetailSpec).Builds;

$(foreach ($build in $Builds) {

if ($build.BuildNumber -match $myBuildNumber)

{

$build.Quality=$myQuality;

$build.KeepForever=$retainBuild;

$BuildServer.SaveBuilds($build);

}

});
hope this helps someone…..

Red ‘x’ on Builds node…..

Number of times we have had bizarre behaviour with Team Foundation Client for Visual Studio….both 2005 and 2008…

1. Red ‘x’ on Builds node… if you closely notice it would be Build instead of Builds….

2. TF31001: Team Foundation cannot retrieve the list of projects from Team Foundation Server…..

Both the above scenarios were specific to local and specific to my workspace…. both the occasions, TFS event log, database connectivity and other basic things were just perfect….others were working good… I was able to guess its something to do locally….

I uninstalled VS, TFPT etc… and reinstalled… still it was challenging…

Finally… one of the posts helped me with the following solution… looked to be something currepted locally…

• Rename “C:\Documents and Settings\<User>\Local Settings\Application Data\Microsoft\Team Foundation\1.0″ or 2.0
• Start –> Run : “devenv /resetuserdata”.

This will reset your Visual Studio user data…..be careful before trying this..

Configuration management metrics….performance indicators

How Integrated Builds, package and deploy process helps to increase overall SDLC productivity…..

Often I see questions, how does good config management help for better productivity or bad config management kills productivity? is there any metrics around that? where do I stand? what should I watch out for?

Here are some common key performance indicators that could help you to review the health of software configuration, build and release management for an integrated development environment.

Problem 1:

High build cycle time….. On an ideal condition for a 900KLOC C# code, complete product compilation can be accomplished in less than 15  minutes with an ordinary build machine….another 20 minutes to package & deploy to a few boxes…..

Problem indicators:

One more level finer, how long does it take you to?

• Generate a candidate build from development environment? Are you experiencing more and often compilation failure? Especially while integrating the code?
• Get it packaged according to the product deployment plan?
• Get those bits deployed on the development environment for initial testing?

Problem 2:

High build rollout time to QA – typically how long does it take you to promote a build to different environments?  a day or more?

Considering candidate build generation is 15 minutes, an efficient build rollout can happen as quickly as 1 hour to any testing environment…..and to as many as 50 tester workstations….

Problem indicators:

• Where do you get stuck? Environment maintenance? More people cook in your kitchen? do people directly manipulate things on the deployed environment rather than maintaining a source controlled version??
• Do you manually double click the .msi and install on every box?
• When you promote the same build to higher environments, should you manually touch up the application configuration parameters according to the environment? Meaning, for dev x=50, for test x=900, how that change is being handled? Manually?
• Do you manually configure your application?
• Release coordination consumes more time to get a candidate build to be promoted to the next level? Possibly due to late integration…check problem #1.
• Have you defined entry and exit criteria for a build?

Problem 3:

How many $$$ do you spend for configuration/build/release management? 100+ hrs for a build rollout? (Possibly because manual build/package/deploy process…. Consumes a lot of time from different roles from release coordinator, build engineer, DBA etc…)
In an ideal world, it need not be more than 2 hrs/per build rollout, may be 5 hrs….

If not…. Here are the problem indicators:

• Manual build/package/deploy
• Manual coordination with external teams like DBA…
• No defined entry/exit criteria..

If your shop is experiencing few or some of the above mentioned challenges…. Certainly there are ways to improve your overall config, build and release management process for an integrated development environment…..get ready to with the following solutions..

Implement Continuous Integration

Many shops still integrate code in an old fashion – say, on a 6 weeks development cycle, 4 weeks independent development (only local builds) and last 2 weeks for integration….typically late integration fakes the progress… lot of hidden tigers will appear when you start to integrate….

If your SCM tool doesn’t support frequent integration, worth considering a switch over to a tool like TFS which supports CI builds out of box….

Do you integrate continuously? NO? are you panic about the frequent changes on your foundational code base..?

Please consider implementing continuous integration – great ways to make sure a code change works well with all others and enables you to test the change immediately in next 30 minutes by efficient build/package/deploy automation…..

Unattended Build/package/deploy process

Build:

• Efficiently automate the build
• Coach the team in such a way that “build break is a crime” – it should get immediate attention and action…

If it’s manual – that certainly hinder your progress… automate the builds… almost all the tools available in the market have the ability for continuous integration and automated build process…. Make sure compiles assembly is ready for testing at the earliest after the change…..

Package:

• Automate the packaging process
• Tightly integrate it along with build process – build process should automatically trigger the packaging..
• Maintain centralized packaging scripts – otherwise you will end up packaging some MS Windows assemblies along with your package..
• Keep it simple and fast… say, if .vdproj takes more time to package something… consider trying a PoC with WiX – in my experience WiX has helped us in reducing the size, time and it’s so flexible….

Automated and integrated packaging process can really boost your dev team productivity.
Consider the current packaging model to be manual… post build, the build server sends out an e-mail… build engineer has to manually copy the assemblies to some location and kick start the packaging process. By the way, he/she might accidently forget some assembly while copying or xcopy might simply fail for an assembly which we did not notice…. the .msi generated off of the manual process certainly fakes the testing… and manual process could be more time consuming as well….

Deploy and post deploy:

• Automate the deploy process – there are plenty of easy tools available like psExec, WinRs, PowerShell scripts etc….
• Integrate deploy with build/package process…. This is awesome to have… if a developer wants to test a code change….he just have to click a button to Q the build on the build server… then it should build->package->deploy off of 1 central id…this gives another ability for you to restrict all other people from accessing the application servers too… so the environment is so clean….
• Establish a process to have an “operational application with bare minimum functionality’ at the end of each business day – create another automated build for the end of each day which deploys the latest bits to the environment
• Establish a build verification test processes
• If possible automate BVT too… sometimes; BVT might be a killer… daily executing some test cases for hrs might irritate the development community…..

Configuration Management

Finally make some changes to Source Control too…..

• Envision the source tree structure in such a way that helps rapid development cycle
• Define efficient check in policies defined to avoid code duplication, confirm unit testing, make sure review process  etc..
• If your team often breaks builds….consider creating some tiny tools to mimic exactly what happens on the build server…like take the latest & build everything locally in a fashion how that happens on the build server..Otherwise teams might not be working in the source control and often code integration results in failure…..

Largely, continuous integration, integrated builds, package, deploy process can really boost your overall SDLC productivity….

cleanup old logs, 1 line script in PowerShell

I was seeking for simple ways to cleanup old logs… google does pull out a lot of stuff, there were plenty of WMI/VBS/.cmd scripts…. however, they were so huge too… I wasn’t really convinced to go for 25+ lines of script just to clean up some log files on regular basis… all I wanted a simple, few lines (not more than 5 lines) of script…..
PowerShell is so sweet… here we go… 3 lines…

$a = get-Date
$a = $a.addDays(-15)
dir <path> | Where-Object { $_.LastWriteTime -lt $a } | remove-item -recurse -force

Upon scheduling this script, it’ll retain only last 15 days of file….delete all old (golden) junks….

I just enhanced it with a foreach to iterate list of files & delete them…. enjoy guys… PowerShell  – all good and powerful stuff…. nice job PowerShell team… this really makes windows simple …

TFS & PowerShell

PowerShell has got excellent features could be useful for SCM tasks….for example, I wanted to monitor history of set of files(say 25) on a weekly basis… I know history command will do but still did not want to do that manual work weekly… if we go for .cmd file… getting the date difference was a challenge… meaning…. everyweek we need to take the history for the past 7 days…which means you need to manipulate date variable… I wasn’t really sure whether its possible in batch scripts…

but powershell does that in 1 line…

executing tf.exe was simple enough…..

here we go….

$TFExecutablePath = “C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\..\IDE\TF.exe”
$file = <path>
$outputFile = <path>

$a=get-date
$a=$a.addDays(-7)
& $TFExecutablePath history $file /version:D$a~T | Out-File -filepath $outputFile -append

So sweet….. though scheduling this script took me a few hours, its great….. enjoy guys….

Schedule a PowerShell script….

C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe “& ‘<path>\<Script>.ps1′ “

To accomplish this, it took me a few hours ….huh….

Three reasons why your opinion is being ignored

Receltly I got chance to go thru this post – this is the fact that many IT Profressionals struggle today…..
http://blogs.techrepublic.com.com/tech-manager/?p=801&tag=nl.e106

Team Foundation Server and Requirements Management….my crudites

It’s been my wish to join the best & brightest group of people who have been actively consuming, woodcrafting, living, loving TFS.  Finally it starts here with my cocktail…. TFS and requirements management…. I’ve tried to be very simple and 1st course of meal provides only the overview and setting the expectation right…what TFS can do for your shop and what not…

Here we go….

Is TFS a comprehensive “requirements management” tool….?????

TFS wasn’t designed specifically to support a requirements management process……However, we can leverage the features to manage the development process…..TFS can help support a productive RM process

How????

2 primary ways
SharePoint or Team Portal
Same as your existing (might be) repository, like a network share for authoring and tracking your specifications
Work Items
TFS provides work item tracking to allow items (bugs, tasks, or in this case, requirements) to be treated as individually managed objects with their own workflows, attributes, and traceability

Team Portal (Sharepoint)

• Team Foundation Server creates SharePoint-based (specifically Windows SharePoint Services) web portals automatically when you create a new project.
• It’s the document library that provides a natural fit for bringing your specifications a little more in line with the rest of the application lifecycle.
• Allows analysts to remain in their comfort application (MS-Word)
• Changes to requirements is much more accessible to those that will consume those requirements (architects, developers, testers, etc.).
• How to access?

1. Team Explorer (either embedded in Visual Studio or as a standalone client)
2. TFS Web Access

Value-add

• Changes are tracked, and linked, at the document level.
• Analysts remain in comfort application (Word, etc.)
• SharePoint is a “natural” extension in Word/Office applications
• Requirement specs are more easily consumed by other roles in lifecycle.
• Provides basic mechanism to enable traceability and better “cross-artifact” reporting.

Drawback

• Still don’t have granular control over individual requirements changes. ‘Lack of item-level granularity’
• Document-level linking only (can’t link to an individual requirement inside specification document)
• Document Workflow managed by SharePoint, whereas Workflow for other lifecycle artifacts are managed by TFS.

WorkItems:

• A fast and flexible way to track any item of record throughout a lifecycle
• Managed by TFS in TFS database
• Provides a proper level of granularity for controlling change and traceability.
• Customizable – Create and customize Work Items – example, we can create work item types that represents Business, Functional, and Non-Functional and have own set of attributes.
• How to access?

1. Team Explorer (either embedded in Visual Studio or as a standalone client)
2. TFS Web Access
3. Excel & Project

Advantages:

• All changes will be recorded and audited
• Links can be created between individual requirements and other work items (any type), source code, test results, and hyperlinks)
• Workflow is enforced and controlled in the same manner as all other work item types
• Supporting information (screenshots, documents, UML diagrams, etc.) can be attached
• Reporting can be much more granular (showing requirement implementation rates, impact analysis, scope creep).
  

Challenges:

• Change of interface may meet resistance (no more Word!)
• Customization work most likely involved (creating custom work item types, fields, & workflow).

Work Item customization – how open is that…..??

• TFS SDK – you can write a custom lightweight interface for business analysts to enter and track requirements work items in TFS.
• SQL Server Reporting Services – to create custom report

we’ll talk more on work items, tracking, customization, 3rd party RM tool integration, reporting in upcoming posts….stay tuned….