STEPS FOR GATED CHECK-IN BUILD PROCESS TO VALIDATE CHANGES

STEPS FOR GATED CHECK-IN BUILD PROCESS TO VALIDATE CHANGES

When a developer checks in changes that break the build, the result can be a significant hassle for small teams. The cost to larger teams can be expensive as measured by lost productivity and schedule delays. You can guard some or your entire code base against this problem by creating a gated check-in builds definition.

When a gated check-in build is created, changes that the developer submits are placed in a shelveset and automatically built in your build system. The build must be successful for the check-in process to be completed. If some of your users must bypass gated check-in, you can set the Override check-in validation by build permission to Allow for a group of your users.

Required Permissions

To perform this procedure, your Edit Build Definition permission must be set to Allow.

To define a gated check-in builds

1. In Team Explorer, click the team project in which you want the build process to function.
2. On the Build menu, click New Build Definition.
3. The New Build Definition window appears with the General tab displayed.
4. In the Build definition name box, type a name.
5. On the Trigger tab, click Gated Check-in accept check-ins only if the submitted changes merge and build successfully.
6. Click the Workspace tab. In the Working folders table, map the version-control folders that this build definition will control to local folders on the build agent.
7. Click the Process tab. In the Items to Build parameter, specify the solutions or code projects that you want to build.
8. Set the parameters to ensure that check-ins meet the specific standards for code quality of your team without delaying your developers unnecessarily.
9. Click the Build Defaults and Retention Policy tabs, and apply appropriate settings in each tab. 

Guidelines to Improve Build Process Function and Performance

To minimize the time that is required to process the build, you should consider following these guidelines when you specify values for the build process parameters on the Process tab.

Required node

·         Items to Build, Configurations to Build: If you leave this parameter empty, the default platform and configuration is used for each solution and project. To optimize performance, adhere to the following guidelines:

·         If a platform-configuration pair builds more quickly than other pairs, specify it in this parameter.

·         Specify as few platform-configuration pairs as possible.

Basic node

·         Automated Tests:

·         For fastest performance, set Disable Tests to True.

·         If your code must pass certain tests, set Disable Tests to False, and then define a set of tests to run in the build. You can improve performance by running only the tests that you require. To designate those tests, filter them by either category or priority.

·         Clean Workspace: For faster performance, set this value to None (recommended) or Outputs. However, your team is more likely to miss some types of defects (such as those introduced during refactoring) if the workspace is not cleaned.

·         Perform Code Analysis: For faster performance, set this value to Never.

·         Source and Symbol Server Settings, Index Sources: For faster performance, set this value to False.

Advanced node

·         Agent Settings

·         Name Filter or Tags Filter: Use either a build agent name or a tag to bind this build definition to a build agent that is designed specifically for running this build. The build agent should run on hardware that is sufficiently powerful to process this build quickly enough to meet your team's performance expectations. For example, developers on your team might not mind waiting 15 minutes for the build to finish. But your developers are not likely to accept having to wait eight hours before they can determine whether their code has successfully checked in.

·         Maximum Execution Time: Set this value to a reasonably small number. For example, 15 minutes might work for your team, but eight hours is probably too long.

·         Copy Outputs to Drop Folder: The system takes this value as False, even if you set it to True.

·         Create Work Item on Failure: The system takes this value as False, even if you set it to True.

·         Label Sources: Set this value to False.

How Gated Check-in Builds are run

Each gated check-in build definition can have only one running build at a time. Therefore, large and active teams are more likely to develop a large queue of gated check-in builds. The following best practices can help your team avoid blocking progress:

• Dedicate a build machine that has powerful hardware (for example, a fast processor and a fast hard disk) to the build agent that your gated check-in build definition uses.
• Define the build so that the build agent does only the work that is required to validate the quality of code that is being checked in.

Gated check-in builds can be run either run automatically or manually.

Automatically Run Gated Check-in Builds

A gated check-in build is run automatically when either of the following events occurs:

• A build has been defined with the Gated Check-in check box selected on the Trigger tab of the build definition.
• Someone attempts to check in one or more changes that intersect with any of the mapped folders in the Workspace tab of the build definition.

Manually Run Gated Check-in Builds and Private Builds

Developers who want to feel more confident about the changes that they are checking in can manually queue a build of a shelveset. When they take this approach, they can specify one of two options for what the system does next if the build succeeds:

System checks in the changes (manual gated check-in build): This option can be handy for developers who want to validate their code before checking in but who work on a team that does not use the gated check-in trigger.

System does not check in the changes (private build): Developers can use this option when they want to validate some changes in a shelveset but not check them in.
 

STEPS TO WORK WITH BUILD NUMBERS

STEPS TO WORK WITH BUILD NUMBERS

You can define your build process to load useful data into the name of each completed build. For example, the default build process (as defined in DefaultTemplate.xaml) loads the following information into  the name of the completed build:

the name of the build definition

the date on which the build was run

an integer that is incremented by one every time that the build definition is repeated on a given date

As a result, a completed build name could resemble this example: DailyBuild_20090824.2.

Syntax for Build Number Expressions

You specify how completed builds are named by using an expression. Consider the following example:

The team project is named ContosoCore.

The build definition is named DailyBuild.

The build ID is 4.

Today is August 24, 2009.

The time is 9:50:43 PM.

The build has been run one time today.

You could set the BuildNumberFormat property to the following value:

$(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)

In this case, the next completed build of DailyBuild would be set to the following build number:

DailyBuild_20090824.2

  

The following table shows how each token is resolved based on the previous example:

Token	Replacement value based on the example earlier in this section
$(BuildDefinitionName)	DailyBuild
$(BuildID)	4
$(DayOfMonth)	24
$(DayOfYear)	236
$(Hours)	09
$(Minutes)	50
$(Month)	08
$(Rev:.rr)	2 (The next build on this day will be 3, and so on.)
$(Date:MMddyy)	082409
$(Seconds)	50
$(TeamProject)	ContosoCore
$(Year:yy)	09
$(year:yyyy)	2009

LIMITATIONS IN TFS 2010

LIMITATIONS IN TFS 2010

There are several limitation exist in TFS 2010 that may affect your team project after is it being created. Let’s examine each of these limitations.

Limitation #1: Renaming Team Project Limitation
            TFS 2010 does not allow you to change team project name after project is created. It is very important to settle on your project name and getting all of the approvals for this name before creating a project in Team Foundation Server. This limitation of changing names does not apply to team project collection however.

Limitation #2: Moving Work Items
            it is impossible to move work items between Team Project due mainly for difference in Team Project templates. For instance, QA team logs a defect into TFS for one of the project but upon reviewing by developers it turns out that this defect applies to a different team with its own team project. It needs to be moved to the other TFS team project space. There is a way to accommodate this by creating a large team project and setting up smaller applications as Area Paths. This way movement of work items can be accomplished without too much trouble.

Limitation #3: Merging and Branching Visualization is not allowed across Team Projects
            It is not a common practice to Brach and Merge your code between team projects and TFS 2010 comes with the limitation when visualization of these changes is not even possible.

Limitation #4: Reporting applies to Team Project only and artifacts are scoped to Team Project
            All of the TFS Reporting capabilities including Dashboard are scoped to Team Project only. If you need to create a report across Team project it may become a challenge. You can however report on project across Area Paths and Iteration Paths. It can also be a consideration for the type of a Team Project you want to create in a first place. In addition, all of the TFS 2010 team project artifacts are scoped to this team project only. This is done primarily to preserve all of the artifact’s linkages within your Team Project. On the other hand, you can create a report that goes against Data Warehouse since it contains information across all Team Projects and Team Project Collections.

Limitation #5: You cannot move Team Projects between Team Projects Collections
            it is not possible to move Team Projects due to conflicts of IDs that each Team Project has. This ID is important for artifacts linkages within TFS 2010. The only possible way to split up a project into is by cloning Team Project Collection and cleaning up each individual Team Project from unwanted artifacts.

Limitation #6: Physical Limitation of your TFS instance
            TFS 2010 has several limitations that may affect the way you design and build your Team Project and Team Project Collections. For example, TFS 2010 can only support up to 100 Team Project Collections and up to 500 team projects.

Limitation #7: TFS Work Item Attachment Size Limit

            Work Item has 4 Mb size limit on attachments by default. However, we can increase this size limit by setting this limit up to 2 gigabytes. In order to do that, we need to use web services that Team Foundation Server provides.

In order to set this limit you have to be a member of the Administrators group on the Application Tier which is a requirement.

Maximum size as it was mentioned is being set using Web Services and you need to access Web Services using your browser and by typing Server Name and WorkItemTracking directory.

http://SERVER:8080/WorkItemTracking/v1.0/ConfigurationSettingsService.asmx?op=SetMaxAttachmentSize

In the maxSize text box you need to enter desired attachment size in bytes and then Invoke it.

ROLE BASED TASK FOR TFS 2010

ROLE BASED TASK FOR TFS 2010

When a team gets started with Visual Studio Application Lifecycle Management (ALM), the Administrator sets up the server, the Project Manager creates a Team Project, and the other Team Members set up their working environments.

Software Development Roles:

1.       Administrator for Team Foundation Server

2.       Project Managers

3.       Source control & build Managers

4.       Individual Team Members

1.      Task for the Administrator of Team Foundation

a.      Install Team Foundation Server by using basic configuration. (TFS 2010 + SP1)

b.      Will be authorised & granted all the required permissions for Project creation during installation of Team Foundation Server.

c.       Need to grant additional users the permissions that they need to act as administrators, project administrators, and other roles.

d.      Maintenance plan that will help ensure your data is backed up in case of a hardware failure or other event.

e.      If your Team will use Visual Studio Lab Management, install Microsoft System Centre Virtual Machine Manager > Configure Lab Management > Create your Virtual Environments.

f.        If your Team will Deploy builds & Run Tests remotely, install Test Controllers & Test Agents on physical or virtual machines.

g.      Install Team Foundation Build by using basic configuration.

2.      Task for the Project Manager

a.      Install the client or clients of Team Foundation i.e. Visual Studio 2010.

b.      Determine your Project Resource Requirements & the Project Collection in which you will create a Team Project.

c.       Choose a Process Template.

d.      Define the Product Areas & Milestones for your Team Project. (Optional)

e.      Grant Team Members the Permissions that need to work in Team Project.

f.        Grant Additional Permissions to specific Team Members (Optional)

Provide additional permissions to team members who will be responsible for managing the source code under TFS Version Control, Managing Builds, Managing Tests & the lab management for Testing, & other project level activities.

1.      Build-level Permissions.

2.      Project-level Permissions.

3.      Area & Iteration-level permissions for work item tracking.

4.      Version Control Permissions.

5.      Lab Management Permissions.

g.      Grant Report authors additional permissions (Optional)

To create or modify reports that access data that is stored in the data warehouse, team members must have read access to the database that makes up the data warehouse.

h.      Notify team members of team project resources and enrolment activities.

i.        Plan your Product.

3.      Task for the Version Control & Build Managers

1.      Configure Version Control.

2.      If using Team Foundation Build, create build definitions for each of your team projects.

4.      Task for Individual Team Members

1.      Install the client or clients of Team Foundation i.e. Visual Studio.

2.      Set up your Workspace for Version Control.

3.      Create, modify & finding tasks & other work Items.

Team Project

Reporting Services

·         Readers   Members of this group can view the project but cannot modify it. ·         Contributors   Members of this group can contribute to the project in multiple ways, such as adding, modifying, and deleting code, and creating and modifying work items. ·         Builders   Members of this group have build permissions for the project. Members can manage test environments, create test runs, and manage builds. ·         Project Administrators   Members of this group can administer all aspects of the team project, although they cannot create projects.

·         Browser   Members of this group can view but cannot modify reports. ·         TFS Content Manager   Members of this group can administer all aspects of the team project, but they cannot create projects.

Team members in these groups or with the assigned permissions	Can access these team project artifacts
Team Foundation Server: Readers, Contributors, or Project Administrators	Work items, work item queries, and source code
Team Foundation Server: Builders	Test environments, test runs, and builds
SharePoint Products: View Only, Read, Contribute, Design, and Full Control	Project portal, dashboards, Office Excel reports, and workbooks
SQL Server Reporting Services: Browser or TFS Content Manager	Reports from SQL Server Report Designer