Customizing Existing Projects


In this section, you will learn how you can customize an existing Team Project to reflect ongoing changes to your process and the needs of your team.

Work Item Queries

To recap, work item queries are the mechanism by which we can find and manipulate work items. The process templates that ship with Visual Studio Team System specify a set of work item queries; however, it is very common for organizations to create their own queries based on specific needs of their team or even rename the work item queries to be more congruous with organizational naming guidelines for work item queries. This section provides step-bystep guidance on how to perform the most common work item query customizations.

Note 

Team Explorer allows for two general categories of work item queries: Team Queries and My Queries. Work item queries available from the Team Queries list in Team Explorer are available to anyone on your project who has the View Project-Level Information permission, which is granted to all project users by default. All project users can have their own work item queries in their own My Queries list. Regardless, renaming work item queries follows the same process in either case. When editing or renaming work item queries that reside in the Team Queries list, you must have the Edit Project-Level Information permission.

Creating a New Work Item Query

  1. In Visual Studio Team Explorer, select your project and navigate to the Team Queries folder.

  2. On the Team menu in Visual Studio, choose Add Query. Alternatively, you can right-click the Team Queries folder in Team Explorer and select Add Query. The New Query window will appear, allowing you to enter filter criteria for your query.

  3. Add filter criteria for your query by populating the And/Or, Field, Operator, and Value columns. You can have many lines in your query with each representing a condition that work items must match for them to get returned in the query results. Use the Field column to specify the work item field you want to evaluate. For example, you might choose the Work Item Type field if you want to create a filter for certain work item types in your project. Use the Value column to specify the value of the field you are evaluating. Use the Operator column to specify the way in which you are evaluating the field value. The And and Or operators are used to specify how multiple filter expressions will be combined to create one complete work item query expression.

  4. Run the query by pressing F5 or by selecting Run Query from the Team menu in Visual Studio to ensure that the results of the query match what you had anticipated.

  5. Save the query by choosing Save New Query on the File menu or by pressing Ctrl+S. The save operation opens the Save Query As dialog box (shown in Figure 7-4), which you can use to name the query and save it in one of the following three forms/locations:

    image from book
    Figure 7-4: The Work Item Query Save Query As dialog box

    • As a Team Query so it appears in the Team Queries section of Team Explorer and is available to the all users with permissions to access your Team Project.

    • As a My Query, which will save the query definition in the My Queries section of a product you can specify. This query will be available only to you.

    • As a file with a name and directory that you specify.

      Tip 

      Saving work item queries as files gives you some additional opportunities for collaboration. For example, as a project manager, you might want to send an e-mail message to instruct your team to review all of the tasks assigned to them and set the state of completed tasks as Closed. You could attach a work item query, called My Outstanding Tasks, that you had already saved to your computer, to provide a convenient way for developers to launch the query to find tasks assigned to them.

Use of Columns in the New Query Dialog Box

The query depicted in the Figure 7-5 searches for all work items in the current project assigned to you that are either a requirement or a change request work item type in a proposed work item state.

image from book
Figure 7-5: Grouping clauses in a work item query

Notice the bracket that connects the work item type clauses. This is a grouping clause and is used to group together more than one condition. In this case, the clause grouping is used to query for either requirements or change requests. Without this grouping, the query would return all proposed requirements or change requests assigned to me.

Figure 7-6 represents a slightly more complex query that you could construct to demonstrate the wide range of possibilities with respect to the work items you can create for yourself or your project team.

image from book
Figure 7-6: Example of a custom work item query

In the work item query shown in Figure 7-6, there are multiple sets of grouped clauses and an example of using a nested clause group.

When creating work item queries, you will need to be familiar with the usage of different operators. Refer to Table 7-3 for a description of the operators you can choose from when building your queries.

Table 7-3: Work Item Query Operator Summary
Open table as spreadsheet

Operator

Description

=

Equals returns values in your work item query expression when there is an exact match to the values you specify.

<>

Does not equal returns values in your work item query when there is no match to the values you specify.

Under

This operator applies to the classification fields Areas and Iterations. You would use the Under operator to look for a value anywhere under a certain branch in the classification tree.

Not Under

The Not Under operator works exactly opposite of the Under operator; use it when you are looking for values that do not appear in any branch under a specified branch of the classification tree.

In

The In operator evaluates a value to determine whether it matches one of a set of values. For example, you can use In to determine if the Test Name value is Test 1, Test 2 or Test 3.

Contains

The Contains operator can be used to search for a substring anywhere in the field value. For example, you can create a query expression that states that the Title field must contain the text test, which will instruct Visual Studio Team System to return work items with titles such as “test1: Enter Description” or “Enter the test details into Visual Studio Team System.”

Does Not Contain

This operator works in the exact opposite manner as the Contains operator, returning rows that explicitly do not contain specified text.

Was Ever

Used to determine if a field ever had a certain value at any time after its creation.

Similarly, you can use a few special comparison values when creating conditions to certain fields: @Project, @Me, and @Today. These comparison values are replaced with the actual values during the execution of the query. For example, @Project will be replaced with the name of the current project. Similarly, @Me will be replaced with the name of the person who is executing the query, and @Today will be replaced with the date that the query is run.

Of course, you can create many new simple queries that are not included in the process templates that ship with Visual Studio Team System. Here are some examples of queries you may want to construct:

  • All Requirements

  • All Functional Requirements

  • Approved Functional Requirements

  • My Outstanding Tasks from All Projects

  • Tasks that have ever been assigned to me

  • All Resolved Bugs in Iteration 1

  • Bugs I have Resolved

Changing the Columns of Your Work Item Query

You will likely want to adjust the columns that appear as a result of a work item query. To add, remove, or reorder columns in work item queries, perform the following steps:

  1. In Team Explorer, right-click a work item query you want to modify and choose View Query to open the Work Item Query Editor (if you already have the Work Item Query Editor open, you can skip this step).

  2. Choose Column Options from the Team menu in Visual Studio to show the Column Options dialog box as shown in Figure 7-7.

    image from book
    Figure 7-7: Changing the column options for a work item query definition

  3. Select the displayed fields by clicking the appropriate arrow buttons in the middle of the Fields tab in the Column Options dialog box. To add a field to the selected columns list, choose the column from the Available columns list and click >. To remove a column from the Selected columns list, select the field from the Selected column list and click <. To change the order of the fields in the Selected field list, use the up and down buttons on the right side of the tab. You can also adjust the width of each displayed column by selecting the column and specifying the width, in pixels, in the width box on the right of the Selected columns list.

  4. Adjust how the work item query will sort the list of work items it returns by clicking the Sorting tab in the Column Options dialog box. To specify a sort order of a column, add and remove columns to the selected columns list in a same way as adding field columns in the previous step. To specify the sort order of a column, select the column from the selected column list and choose the direction of the sort (ascending or descending) by using the buttons to the right of the selected columns list.

  5. Click OK to save the column options for your work item query.

Making a Copy of a Work Item Query

Sometimes it is better to make a copy of an existing work item query before making changes to its definition. A good example of this is taking a work item query that is a Team Query and copying it to your personal My Queries, where you are able to make changes to the work item type definition without affecting anyone else on your team. When you are finished, you can also copy the work item query you just modified back to Team Queries, either overwriting an existing work item query or adding it to the existing list.

To copy a work item query, perform the following steps:

  1. Find the work item query you want to copy from either of the query lists Team Queries or My Queries.

  2. Right-click the work item query and select Copy from the shortcut menu.

  3. Select the destination of the work item query, either Team Queries or My Queries.

  4. Right-click the destination list and choose Paste from the shortcut menu.

    Tip 

    Moving work items queries between the Team Queries and My Queries lists is very similar to copying. Simply perform the preceding steps but choose Cut instead of Copy from the shortcut menu.

Renaming a Work Item Query

Renaming work item queries is very common and straightforward. It is common for organizations to completely change the names of all work item queries on a project to make it easier to navigate through large numbers of work item queries in Team Explorer. For example, instead of having work item queries called All Bugs and Active Bugs, project managers will rename the work item queries Bugs–All and Bugs–Active. This makes a lot of sense if there are a number of variations of Bug queries, because the queries are sorted alphabetically in Team Explorer to make it easier to find the set of work item queries that deal with bugs.

To rename a work item query, perform the following:

  1. In Team Explorer, right-click the work item query you want to rename from either the Team Queries list or the My Queries list and select Rename.

  2. Type the new name and press Enter.

Source Code Control

From a project manager’s perspective, there are really only a few customizations you will need to make to the source control features of Visual Studio Team System: adding check-in notes, adding check-in policies, and changing permissions to source control folders. Again, in larger organizations, these tasks should likely be left up to the technology lead for the project, especially setting up permissions. However, on smaller and more agile teams, the project management role could be shared with the technology lead or software architect. This section will explore how to perform the most common customizations to source control to your existing Team Projects.

Modifying Check-In Notes

Check-in notes allow the developers to capture additional information about a check-in operation. Process templates provide three default check-in notes: Code Reviewer, Security Reviewer, and Performance Reviewer. Check-in notes can be made mandatory, preventing the check-in operation if ignored by the developer. You can easily modify the default list of checkin notes either by adding new check-in notes or by modifying existing ones. Again, you will need Edit Project-Level Information permission to perform this action.

To modify check-in notes, perform the following steps:

  1. In Team Explorer, click the project whose check-in policies you want to modify. On the Team menu, point to Team Project Settings, and then click Source Control. The Source Control Settings dialog box appears.

  2. Click the Check-in Notes tab to show the options for managing check-in notes.

  3. To make an existing check-in note required, select the check box to the right of the corresponding check-in note.

  4. To create a new check-in note, click Add to show the Add Check-in Note dialog box. Type a name for the new check-in note and indicate whether the new note is required or not. Click Add to add the new check-in note to the list of check-in notes for the project.

    Warning 

    Many organizations embrace check-in notes, going so far as making a number of them mandatory. This might initially seem like a good idea because it could help lead to greater conformity, but it won’t make your developers very happy. As a general rule, you should try not to put many obstacles in front of your developers when they check in source code because this may discourage them from doing this when they need to. Mandatory check-in notes cannot be ignored, and if the developer is overloaded with notes that must be filled in, there is a greater chance that the value of the content of the notes will diminish or contain irrelevant information such as random key strokes.

Modifying Check-In Policies

A check-in policy is a rule that must be met before source code can be checked into Team Foundation Server. By far, the most common check-in policy is the Work Item check-in policy, which promotes the association of the check-in operation with one or more work items in a project. By default, Visual Studio Team System provides that plus two additional check-in policies: Testing Policy and Code Analysis. Testing Policy ensures that tests from specific test lists are successfully executed before checking in. Code Analysis requires that code analysis be performed on the project prior to check-in. You can easily change which default source control policies are enforced for your team by following these steps:

  1. In Team Explorer, select the Team Project whose check-in policies you want to change.

  2. On the Team menu, select Team Project Settings | Source Control to show the Source Control Settings dialog box.

  3. Click the Check-in Policies tab, on which you can add, edit, remove, enable, and disable installed check-in policies.

  4. To add a check-in policy, click Add and select from the list of available check-in policies. Some policies, such as the Code Analysis policy, require configuration-you will be prompted to specify the specific code analysis rules that will be executed.

    Note 

    It is possible to create a new check-in policy; but the procedure is quite technical and. therefore, beyond the scope of this book. It will suffice to tell you that user-created check-in policies appear in the list of check-in policies just as the three that are provided with the product.




Managing Projects with Microsoft Visual Studio 2005 Team System
Managing Projects with Microsoft Visual Studio 2005 Team System
ISBN: 735622167
EAN: N/A
Year: 2007
Pages: 93

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net