Customizing Process Templates


In order to create a Team Project, you must first select a process template. In fact, Microsoft included two MSF templates available by default: MSF for Agile Development and MSF for CMMI Process Improvement (you can learn about these frameworks in Chapter 21).

These default templates are usually stored in Team Foundation Server and are retrieved using the New Team Project Wizard. It is highly doubtful that these default templates will fit your needs perfectly. Like many other parts of Team System, process templates are customizable and extensible. In this section, you'll get an end-to-end overview on how to export, design, and import your own process templates.

The workflow process of customizing templates is quite straightforward. At this stage, all that is required to modify process templates is a text editor. To upload your work, you can use the Process Template Manager. To access the Process Template Manager, simply select Team image from book Team Foundation Server Settings image from book Process Template Manager. You can also access the Process Template Manager by right-clicking your Team Foundation Server icon in the Team Explorer and selecting Team Foundation Server Settings image from bookimage from book Team Foundation Server Settings image from book Process Template Manager.

  • The Process Template Manager will open (as shown in Figure 22-2).

    image from book
    Figure 22-2

  • Select MSF for Agile Software Development – v4.0 (default).

  • Click the Download button on the right.

  • Navigate to your desktop and click Save. Your process template will download to your desktop and you will receive the following message: "Process Template downloaded successfully" (as shown in Figure 22-3).

  • Note

    The "Full Process" version of MSF is your best bet if you want to integrate both process and template customizations. As mentioned in the section "Obtaining the Microsoft Solutions Framework," in Chapter 21, you can download the full process template on the Team System MSF website (http://www.msdn.microsoft.com/msf.

    Navigating a process template

    Once your files have been exported, they will appear as shown in Figure 22-4. All the exported files are part of the Process Template Definition.

    image from book
    Figure 22-3

    image from book
    Figure 22-4

    The following are the components of a Process Template Definition. In the section that follows, you'll learn how to manipulate all parts of the Process Template Definition to make it suit your custom or in- house process:

    • ProcessTemplate.xml. Base template definition of the process itself that consists of configurable elements such as the Project Portal and the reports site, for example.

    • Classification. Project definitions.

    • WorkItem Tracking. Work item types and query definitions.

    • Groups and Permissions. Groups and permissions definitions.

    • Reports. Report definitions.

    • Version Control. Version control definitions.

    • Windows SharePoint Services. SharePoint Portal Stylesheet definitions, including process guidance.

    Modifying template definitions

    ProcessTemplate.xml contains three pieces of information about your process: the name, the description, and the plug-ins required to create a project. Plug-ins are used to extract Work Products (Word, Excel, Project, or Visual Studio documents), directories, and other important files from compressed process templates (stored as binary objects) on Team Foundation Server.

    To add a unique name for your new process template, edit ProcessTemplate.xml. At the beginning of the file, you'll find two nodes: name and description. name is a required element. The description should explain the process template in a short paragraph and distinguish it from other processes. Simply edit the nodes as follows:

         <?xml version="1.0" encoding="utf-8" ?>     <ProcessTemplate>     <metadata>     <name>My New Process</name>     <description>This custom process is used in the development team at company  XYZ.</description> 

    The name will appear on the process template list in the Create New Project Wizard. The description will appear right below. Figure 22-5 shows how the information appears in the New Project Creation Wizard.

    The next part of the XML file contains a list of the required plug-ins in your process template. Let's say that your process requires no changes to the SharePoint Team Site. You could then omit the following line from the list of plug-ins:

            <plugin name="Microsoft.ProjectCreationWizard.Portal" wizardPage="false"/> 

    image from book
    Figure 22-5

    Here are the default plug-ins you will find in any Team System process template:

         <plugins>     <plugin name="Microsoft.ProjectCreationWizard.Classification" wizardPage="false"/>     <plugin name="Microsoft.ProjectCreationWizard.Reporting" wizardPage="false"/>     <plugin name="Microsoft.ProjectCreationWizard.Portal" wizardPage="true"/>     <plugin name="Microsoft.ProjectCreationWizard.Groups" wizardPage="false"/>     <plugin name="Microsoft.ProjectCreationWizard.VersionControl" wizardPage="true"/>     <plugin name="Microsoft.ProjectCreationWizard.WorkItemTracking" wizardPage="false"/>     </plugins>     </metadata> 

    This plug-in section is extremely important because it defines what parts of your process template will be enabled in your project. The purpose of each plug-in will be covered throughout the chapter.

    This part of the process template is comparable to a .NET build manifest. It contains all of the necessary steps to define a complete Team project. When you transfer this file to Team Foundation Server, it is automatically zipped (along with the files associated with your process). The MetaData.xml file is used to provide information about your process.

    The core template

    The rest of the process template contains similar information as the meta-data portion of the file, with one important difference: it outlines the dependencies between plug-ins. A plug-in is an agent that extracts and sets up the files required for part of your process guidance. Each plug-in will use an associated Task.xml file to correctly build your process guidance within a Team Project. For example, once a Team Project is generated, the Microsoft.ProjectCreationWizard.Classification plug-in will access the Classification.xml file within the Classification directory and perform all associated tasks. wizardPage is a required attribute that indicates whether the plug-in requires a configuration page in the wizard.

    Some plug-ins are dependent on others to be able to run — in particular, when security settings or permissions are required. For better manageability, you should order your tasks and dependencies in the same order. Table 22-2 outlines the dependencies between plug-ins.

    Table 22-2

    Plug-in Name

    Dependencies

    Microsoft.ProjectCreationWizard.Classification

    Has no dependencies but is required to set up a project

    Microsoft.ProjectCreationWizard.WorkItemTracking

    The WorkItemTracking plug-in relies on the Classification plug-in and Groups plug-ins. WorkItemTracking is a non-required plug-in (that is, you can use third- party work item management tools to manage your life cycle).

    Microsoft.ProjectCreationWizard.Groups

    The Classification plug-in is required to use the Groups plug-in. The Groups plugin is non-required.

    Microsoft.ProjectCreationWizard.Reporting

    The Reporting plug-in requires the Classification and the Groups plug-ins. Otherwise, it is a non-required plug-in.

    Microsoft.ProjectCreationWizard.VersionControl

    The Classification plug-in is required to use the Version control plug-in. The Version control plug-in is non- required (i.e., you can use third-party version control tools and/or repositories to manage source code).

    Microsoft.ProjectCreationWizard.Portal

    The Portal plug-in has no dependencies and is not required to create a Team Project.

    The plug-in dependencies are outlined in the group portion of the ProcessTemplate.xml file. In the following example, the WorkItemTracking plug-in is dependent on the Classification plug-in and the Groups plug-in:

         <group              description="Workitem definitions uploading."             completionMessage="Workitem definitions uploaded.">             <dependencies>                 <dependency group/>                 <dependency group/>             </dependencies>             <taskList filename="WorkItem Tracking\WorkItems.xml"/>         </group> 

    All plug-in groups are organized as one task group for every plug-in. A taskList defines work or configurations within a Team Project, such as creating a new report type, adding new Team Portal files, and so forth.

    In the following example, the version control plug-in will set default permissions, check-in notes, and exclusive check-out settings using the version control task file (VersionControl.xml):

         <?xml version="1.0" encoding="utf-8" ?>     <tasks>         <task                name="Create Version Control area"               plugin="Microsoft.ProjectCreationWizard.VersionControl"               completionMessage="Version control Task completed.">             <dependencies/>             <taskXml>                 <permission allow="Read, PendChange, Checkin, Label, Lock, ReviseOther,     UnlockOther, UndoOther, LabelOther, AdminProjectRights, CheckinOther"     identity="[$$PROJECTNAME$$]\Project Administrators"/>                 <permission allow="Read, PendChange, Checkin, Label, Lock"     identity="[$$PROJECTNAME$$]\Contributors"/>                 <permission allow="Read" identity="[$$PROJECTNAME$$]\Readers"/>                 <permission allow="Read, PendChange, Checkin, Label, Lock"     identity="[$$PROJECTNAME$$]\Build Services"/>                 <checkin_note label="Code Reviewer" required="false" order="1"/>                 <checkin_note label="Security Reviewer" required="false" order="2"/>                 <checkin_note label="Performance Reviewer" required="false" order="3"/>                 <exclusive_checkout required="false"/>             </taskXml>         </task>     </tasks> 

    The next section describes in greater detail how to control the setup of Team Foundation Version Control.

    Team Foundation version control

    The primary file to control the Team Foundation version control settings within your process is called VersionControl.xml. The version control plug-in (Microsoft.ProjectCreationWizard.VersionControl) will enable you to set up features such as permissions, check-in notes, and checkout policies.

    You first define a task to create the source code repository in your project:

         <?xml version="1.0" encoding="utf-8" ?>     <tasks>        <task               name="Create Version Control area"              plugin="Microsoft.ProjectCreationWizard.VersionControl"              completionMessage="Version control Task completed.">            <dependencies/> 

    Then you can programmatically set the permissions for each of the security groups on Team Foundation Server (for more information on configuring Team Foundation security groups, please refer to Chapter 19):

         <taskXml>       <permission allow="Read, PendChange, Checkin, Label, Lock, ReviseOther,     UnlockOther, UndoOther, LabelOther, AdminProjectRights, CheckinOther"     identity="[$$PROJECTNAME$$]\Project Administrators"/>       <permission allow="Read, PendChange, Checkin, Label, Lock"     identity="[$$PROJECTNAME$$]\Contributors"/>       <permission allow="Read" identity="[$$PROJECTNAME$$]\Readers"/>       <permission allow="Read, PendChange, Checkin, Label, Lock"     identity="[$$PROJECTNAME$$]\Build Services"/> 

    If you want to give your contributors the rights to read their peer's source code, you can easily add ReviseOther, UnlockOther, UndoOther, and Checkin rights to the Contributor role in the XML file:

         <permission allow="Read, PendChange, Checkin, Label, Lock, ReviseOther,     UnlockOther, UndoOther, LabelOther, CheckinOther"     identity="[$$PROJECTNAME$$]\Contributors"/> 

    The next part of the XML file enables you to set the check-in notes. First, preliminary roles are set up corresponding to the groups responsible for governance. For example, a code reviewer may be responsible for verifying the integrity of code (in a peer programming environment), or a manager has to check the source code before it is checked into an important part of the version control tree. You can view the check-in note configuration page via the Source Control settings within your Team Project. (Right-click your project in the Team Explorer and select Team Project Settings image from book Source Control image from book

    Note

    Unfortunately, most source code control policies can't be set by default using a custom process template. You must create policies and manually enable them within your Team Project. You can learn more about source control policy customization by looking at the Team System Extensibility SDK. James Manning has a great code sample and article on how to scan the history for the changesets that had policy overrides. You can read more about it here: http://www.blogs.msdn.com/jmanning/archive/2005/11/04/489193.aspx. Marcel de Vries (a Team System MVP) also has a blog post on how to receive e-mail on a Team Foundation check-in policy violation: http://www.blogs.infosupport.com/marcelv/archive/2005/10/18/1635.aspx.

    Check-in notes are used to explain the reasons why source code has been checked in. Several scenarios are possible, including doing a code review or fixing a special bug. You can add a check-in note using the following syntax:

          <checkin_note label="Custom Review" required="true" order="1" /> 

    You can use the exclusive check-out element to specify whether one developer or several developers can simultaneously check out source files. If you set the attribute to "true", you limit the number of people that can access a source file to one per file! A "false" value will allow multiple developers to check out files and manage the changes once the files are checked out. Here is an example of the code to enable exclusive check-out:

          <exclusive_checkout required="true"/>     </taskXml>     </task>     </tasks> 

    Several states are available for source code file permissions. Table 22-3 outlines the important permissions and their associated descriptions.

    Table 22-3
    Open table as spreadsheet

    Permission

    Description

    AdminProjectRights

    The user can configure source code control security.

    Checkin

    The user can check in updated source code.

    CheckinOther

    The current user can check in using another user's credentials. You must have the required credentials to use conversion tools.

    Label

    The user can add a label to a source code item.

    LabelOther

    The current user can change a label created by another user.

    Lock

    The current user can lock source code items, preventing other users from manipulating them.

    PendChange

    The user is given the capability to manipulate a changeset, and can branch, merge, delete, undelete, add, check out, and perform other relevant activities.

    Read

    The user can read any source code file or associated folder.

    ReviseOther

    The current user can manipulate another user's check-in notes and comments for a changeset.

    UndoOther

    The current user can undo a pending change created by another user.

    UnlockOther

    The current user can remove another user's lock.

    Note

    The Team Foundation version control folder is created using the New Team Project Wizard.

    When you create a Team Project, you can check the custom settings you've added to your process template. To verify that all features and configuration work as advertised, follow these steps:

    1. Upload your process template (as described at the end of the chapter in the section "Uploading process templates in Team Foundation Server").

    2. Start a new Team Project using your new process template.

    3. Right-click on your Team Project and select Team Project Settings image from book

      Simply add a new work item type using the WORKITEMTYPE element to point to the specific type definition for your custom type. For example, if you were building a Time Tracking type, then you would insert the following within the WORKITEMTYPES node:

            <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\TimeTracking.xml"/> 

      You then must create a file called TimeTracking.xml within your TypeDefinitions folder. You have the choice of copying the fields and layout of an existing work item and customizing it to your needs, or, if you are adventurous, you can create a work item from scratch.

      Please refer to Chapter 19 for more information on the anatomy of a work item and how to build custom work items for your project.

      Work item queries

      Work item queries function to group together work items by criteria such as category or by the value of a specific field. All the work item queries can be found in the Queries folder within the WorkItem Tracking directory. All work item queries files end with a .wiq extension. Here is an example of the All Work Items query located in AllWorkItems.wiq:

           <?xml version="1.0" encoding="utf-8"?>     <WorkItemQuery Version="1">         <Wiql>SELECT [System.Id], [System.WorkItemType], [Microsoft.VSTS.Common.Rank],     [System.State], [System.AssignedTo], [System.Title] FROM WorkItems             WHERE [System.TeamProject] = @project AND [System.State] &lt;> 'Closed'             ORDER BY [Microsoft.VSTS.Common.Rank], [System.WorkItemType], [System.Id]         </Wiql>     </WorkItemQuery> 

      If you want to create custom queries from scratch using an editor, we recommend you study the WorkItemType data constructs within SQL Server 2005.

      From a practical perspective, work item queries can be accessed by anyone on your team because they are an integral part of your project. Team Explorer is the easiest tool to use when you create a customized work item query. You can then save the work item query (into a .wiq file) using the following steps:

      1. Right-click on a query in Team Explorer and select Query View.

      2. Choose Save As in the File menu and select a name.

      3. Select a location and name for your .wiq file.

      4. Copy your new query file into the Queries folder within the WorkItem Tracking directory of your custom template.

      You then have to add the query to your template. The QUERIES portion of the workitems.xml file has the following structure:

           <task            name="Stored Query Definitions"      plugin="Microsoft.ProjectCreationWizard.WorkItemTracking"      completionMessage="Queries uploaded"      completionDescription = "Processing the stored queries used by work item  tracking">     <dependencies>        <dependency task />        <dependency task />     </dependencies>     <taskXml>     <QUERIES>     <Query name="My Work Items" fileName="WorkItem Tracking\Queries\MyWorkItems.wiq" />     <Query name="All Tasks" fileName="WorkItem Tracking\Queries\AllTasks.wiq" />     <Query name="Active Bugs" fileName="WorkItem Tracking\Queries\ActiveBugs.wiq" />     ...     </QUERIES>     </taskXml>     </task> 

      Simply insert the following line of code within the QUERIES element to include your custom work item query:

           <Query name="Custom Query" fileName="WorkItem Tracking\Queries\CustomQuery.wiq" /> 

      Work item instances

      You can define what work items should be instantiated when a Team Project is created. If you look at the workitems.xml file, you'll notice a lengthy section within the task element. This block of XML code will create an instance of a task work item. The first part of the code block defines what plug-in to use, a completion message, and a task description. You can customize these messages as you see fit:

           <task            name="WorkItems" plugin="Microsoft.ProjectCreationWizard.WorkItemTracking"      completionMessage="Work items uploaded"      completionDescription = "Processing the actual work items used by work item     tracking">     <dependencies>      <dependency task />     </dependencies> 

      The next part of the code block enumerates the work items to be included by default in a project. Here is an example of the "Set Permissions" task:

           <WORKITEMS>     <WI role="Task">     <FIELD refname="System.Title" value="Setup: Set Permissions" />     <FIELD refname="System.IterationPath" value="$$PROJECTNAME$$\Iteration 0" />     <FIELD refname="System.State" value="Active" />     <FIELD refname="System.Reason" value="New" />     <FIELD refname="Microsoft.VSTS.Common.Issue" value="No" />     <FIELD refname="Microsoft.VSTS.Common.ExitCriteria" value="Yes" />     <FIELD refname="System.Description" value="Using the admin UI in VS add users to     one of the 3 groups: Project administrators, Contributors or Readers." />     </WI>...     </WORKITEMS>     </taskXml>     </task> 

      You can use the WI element to define the work item type and the FIELD element to specify the attributes and values assigned to your work item. The attributes outlined in the preceding example are required fields.

      Note

      We can't emphasize enough how important it is to define the correct structure for your work items. In most cases, try to clone a preexisting work item and tailor it to your needs. Otherwise, problems may occur — for example, when you try to map work item fields to Microsoft Project columns.

      Testing your changes

      The last step you must take to verify that your queries, instances, and type definitions are valid is uploading a new process template and trying to create a Team Project using your customized template. To test your work item customizations, follow these steps (you may need to repeat some of these steps for each work item type, instance, and query you have created):

      1. Upload your custom process template to the Team Foundation Server. (See the section "Uploading process templates in Team Foundation Server" at the end of the chapter.)

      2. Create a new Team Project using your template. The Team Project creation process is outlined in detail in Chapter 19.

      3. Within the Team Explorer, right-click the Work Items node.

      4. Choose the Add Work Item option and select one of your custom work items.

      5. Verify the structure and layout of fields in your custom work item.

      6. Run usability tests on your work item. Try out all of the field states and conditions.

      7. Verify whether your query exists in the My Queries node inside Team Explorer.

      8. View the results of a query by right-clicking on it and selecting View Results. Make sure that the results are the ones you are expecting!

      9. Run the All Work Items query. Make sure your custom work items appear.

      You can also modify work items on existing projects using the witimport and witexport tools. Please refer to the Visual Studio 2005 SDK for more information (available at http://www.vsipdev.com).

      Windows SharePoint Services team portal

      From within the process template, you can define elements such as process guidance, document templates, SharePoint templates, and other important files stored on the Team Project Portal. Windows SharePoint Services artifacts are created using the Windows SharePoint plug-in (Microsoft.ProjectCreationWizard.Portal).

      From within the process guidance folder (Agile or CMMI), the Windows SharePoint Services directory contains all the files you need to manipulate the portal guidance and template. Within this directory, you will find several folders:

      • Process Guidance. This folder contains HTML and XML versions of your process guidance files. See the section earlier in this chapter entitled "Customizing Process Guidance" for more information on customizing that part of the project.

      • Work Product Folders. These contain work products (templates and supporting files) for project management, security, requirements and test.

      Note

      Any directory, file, or template contained in the Windows Sharepoint Services directory can be updated and customized to fit your process requirements.

      Document template schema

      The WssTasks.xml file located in the Windows Sharepoint Services directory contains an enumeration of all the SharePoint elements found within your custom process. The file is divided into three sections. The first section lists all of the document libraries (including titles and descriptions) related to your process. This is a high-level way of categorizing your documents — you can easily add and remove any of these categories based on your needs. Please note that these libraries are accessible when you click the Documents and Lists link on the main page of the project portal.

            <?xml version="1.0" encoding="utf-8" ?>      <tasks>        <task               name="Create Sharepoint Portal"              plugin="Microsoft.ProjectCreationWizard.Portal"              completionMessage="Project site created.">      <dependencies/>      <taskXml>      <Portal>      <site template="VSTS_MSFAgile" language="1033"/>     <documentLibraries>        <documentLibrary name="Security" description="Documents for the architect team"/>        <documentLibrary name="Test" description="Documents for the test team"/>      ...      </documentLibraries> 

      The folders node lists all the folders within specific document libraries. The example defines the folders found in the Process Guidance library:

           <folders>        <folder documentLibrary="Process Guidance" name="Supporting Files"/>        <folder documentLibrary="Process Guidance" name="Supporting Files/Code" />        <folder documentLibrary="Process Guidance" name="Supporting Files/CSS" />        <folder documentLibrary="Process Guidance" name="Supporting Files/EULA" />        <folder documentLibrary="Process Guidance" name="Supporting Files/HTML" />        <folder documentLibrary="Process Guidance" name="Supporting Files/images" />        <folder documentLibrary="Process Guidance" name="Supporting Files/Other" />        <folder documentLibrary="Process Guidance" name="Supporting Files/Schema" />        <folder documentLibrary="Process Guidance" name="Supporting Files/XML" />        <folder documentLibrary="Process Guidance" name="Supporting Files/XSLs" />     </folders> 

      The Files section of WssTasks.xml lists all of the files to be included into a Team Project once your process file has been selected. These include process guidance files and work products:

           <files>     <file source="Windows SharePoint Services\Process Guidance\ProcessGuidance.html"           target="Process Guidance/ProcessGuidance.html" />     <file source="Windows SharePoint Services\Process Guidance\Supporting           Files\AboutRoles.htm"           target="Process Guidance/Supporting Files/AboutRoles.htm" />     ...     </files>     </Portal>     </taskXml>     </task>     </tasks> 

      Adding new work products to your team portal

      Adding a work product within your process is quite easy using XML. Simply define the path to your source file and the target path of the folder on the server (as defined in the documentLibraries collection):

             <file source="Windows SharePoint Services\Templates\YourPolicy.doc"       target="Security/YourPolicy.doc" /> 

      Customizing the team portal

      There may be circumstances where you will need to modify the "look-and-feel" and structure of the Team Portal. It's important to establish an identity for the site, and doing so will help your team mem- bers feel ownership of it. SharePoint customization (such as creating site definitions and custom Web parts) is out of scope for this book. However, we'll provide you with solid, basic instructions to change the look of the site.

      Adding your custom logo to the team portal

      Here are the steps to add a custom logo to the portal. SharePoint Services site customization is primarily done using FrontPage 2003. You can also use an XML editor to make style changes by hand:

      1. Launch FrontPage 2003.

      2. Click File image from book Open Site.

      3. Type the URL of the site you want to customize. For example: http://www.tfs/sites/MyCustomSite.

      4. You may be prompted for an administrative username/password.

      5. The site will come up in the editor.

      6. Click the "images" folder in the folder list on the left side of the screen.

      7. Use File image from book Import and select the custom logo you designed. This will upload the logo into the images folder.

        Note

        You can use a similar technique to upload custom Web Parts (.dwp) files. Before clicking the Import option, open up the folder list and select_catalogs image from book wp (Web Part Gallery). That will make it available on the site when you select Modify Shared Page on the portal site.

      8. Select the current MSF logo and hit the Delete key to remove it.

      9. Open the images folder from the treeview on the left side of the screen and drag and drop your new custom logo into the placeholder in the design view of the portal.

      10. Save your changes.

      Saving your changes will make your customizations automatically appear on the project portal. You can customize everything from site colors to the graphics on the page. Most of the styles are contained in stylesheets in the themes directory.

      Saving your custom site template

      You now have one of two choices: You can customize each site on a one-by-one basis, or you can save your work as a SharePoint site template and associate it to your process template. The latter option makes sense if you are planning to reuse a process template over and over again. It saves you from having to take the manual steps to customize the "look-and-feel" after creating each project portal. Here are the steps to create a site template file.

      1. Open your customized Team Portal.

      2. Click Site Settings.

      3. Click Go to Site Administration on the Administration menu.

      4. Under Management and Statistics, click Save Site as Template.

      5. You will now have the option of creating a new filename for your custom template (filename.stp). You can also add in a template title and description.

        Important

        We recommend that you omit any spaces from your template filename.

      6. There is a checkbox on the form that says "Include content." This will include all the files that are currently part of your team portal. If you think that you will reuse all of the same files on the portal everytime you create a Team Project, click on the checkbox. Otherwise, leave it unchecked.

      Your template has now been saved.

      Here are the instructions to obtain a copy of the site template as a .stp file. The .stp file is actually a .cab (Cabinet) file that contains an XML manifest describing the structure of the site and a collection of compressed files with your template's assets. Follow these steps:

      1. From the home page of your portal, click Site Settings.

      2. Under Administration, click Go to Site Administration.

      3. Under Site Collection Galleries, click Manage Site Template Gallery.

      4. Click your template and download the .stp file to your C:\ drive.

      Now, you need to make SharePoint recognize the new template and modify the process template. Assuming that you put your custom .stp file in the root of the C:\ drive, type the following command using the command prompt and hit Enter:

           > cd C:\ 

      Then type the following to add the custom site template to Team Foundation Server:

          > "C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\bin\    stsadm.exe" -o addtemplate -filename mycustomtemplate.stp -title customtemplate 

      In the preceding example, the filename for your custom template is mycustomtemplate.stp. You also designated customtemplate as the identifying title for the template. The title is quite important, as it is used to link the site template to your process template. Once your site template has been added, all you need to do is to make a small customization in your process template.

      Integrating a site template within a process template

      At this point, all you need to do is link the process template to the site template. Here are the steps to integrate both together.

      1. Download a copy of a process template to your desktop as described at the beginning of the chapter.

      2. Open the Windows Sharepoint Services folder and edit WssTasks.xml in your favorite XML editor.

      3. Update this site node, changing the template to your custom template title. For example:

              <site template="customtemplate" language="1033" /> 
      4. Upload your customized process template. (The steps are described in the section "Uploading process templates in Team Foundation Server.") Before you do that, you may want to rename the title of the process.

      Now every time you create a new Team Project using your custom process, a Team Portal will be gener- ated with your custom logo and colors.

      Verifying your portal customizations

      The best way to check your custom SharePoint setting is by creating a brand-new project incorporating your custom process template. To test your customized process template, use the following steps:

      1. Upload your custom process template to the Team Foundation Server (see the section "Uploading process templates in Team Foundation Server" at the end of the chapter).

      2. Create a new Team Project using your template. The Team Project creation process is outlined in detail in Chapter 19.

      3. Select the Show Project Portal option by right-clicking on your Team Project within the Team Explorer window.

      4. Select the Documents and List option at the top of your project portal.

      5. Click Document Libraries to see whether they were properly created.

      6. You can then click on individual files to determine whether they are located in the right docu- ment libraries.

      SQL Reporting services

      You can use the Reporting plug-in (Microsoft.ProjectCreationWizard.Reporting) to manage many aspects of Team System's reporting engine, including the creation of the preliminary default reports that appear on the project portal when you use the New Team Project Wizard. All of the configuration information is contained in a file called ReportsTasks.xml located in the Reports folder in your process template. Within this file, you can set iterations, groups, and permissions and define what reports will appear on the Project Site.

      Note

      You can learn how to create custom reports and use tools such as the Report Builder in the "Team Reporting" section of Chapter 19.

      Let's take a look at how reporting is configured within your custom process template. You can use the site element to define the path of your project's reporting site (the following example indicates the default value):

           <?xml version="1.0" encoding="utf-8" ?>     <tasks>     <task            plugin="Microsoft.ProjectCreationWizard.Reporting"      completionMessage="Project Reporting site created.">     <dependencies/>     <taskXml>        <ReportingServices>           <site />        </ReportingServices>     </taskXml>     </task> 

      Folders can be created for your reporting site using the folder element placed inside the ReportingServices element. You define the location using a relative path, as shown here:

           <ReportingServices>     <folders>     <folder path="Public"/>     </folders>     </ReportingServices> 

      Reports are represented in the process template as files with an .rdl extension. These files can easily be swapped in and out of your template using the report element. Here is an example of a Bug Rates report from the MSF Agile process template:

           <report name="Bug Rates" filename="Reports\Bug Rates.rdl" folder="" cacheExpiration     ="30">        <parameters>           <parameter name="Project" value="$$PROJECTNAME$$"/>        </parameters>        <datasources>           <reference name="/TfsOlapReportDS" dsname="TfsOlapReportDS"/>        <reference name="/TfsReportDS" dsname="TfsReportDS"/>        </datasources>     </report> 

      To create a link between your project property and a report, use the $$PROJECTNAME$$ value to tell the server to use the current Team Foundation Server. Properties are used to describe characteristics of a report:

           <properties>        <property name="" value=""/>     </properties> 

      The datasource element is one of the most important within a report. It enables you to connect a data source name to SQL Server 2005 (via Team Foundation Server). In the following example, the data source name is TfsReportDS:

           <report name="My Bugs" filename="Reports\My Bugs.rdl" folder="">        <parameters>          <parameter name="Project" value="$$PROJECTNAME$$"/>        </parameters>        <datasources>          <reference name="/TfsReportDS" dsname="TfsReportDS"/>        </datasources>     </report> 

      Verifying your report status

      After you customize the portal's custom reports, it is important to ensure that it will create new reports once a project is instantiated. Follow these steps to validate the creation of Team System reports:

      1. Upload your custom process template to the Team Foundation Server (see the section "Uploading process templates in Team Foundation Server" at the end of the chapter).

      2. Click the Reports folder in your project within Team Explorer.

      3. Execute and test each report.

      Note

      Connectivity is key for the functioning of a report. If any data is missing, the report may not render correctly.

      Classification

      If you want to control the iterations and items within a project, the Classification plug-in (Microsoft.ProjectCreationWizard.Classification) will handle these tasks. The Classification.xml file contains all of the config information to allow you to define iteration hierarchies.

           <?xml version="1.0" encoding="utf-8" ?>     <tasks>     <task            name="Creating project structure"      plugin="Microsoft.ProjectCreationWizard.Classification"      completionMessage="Portfolio project structure created.">     <taskXml>     <Nodes> 

      Iterations define how many times a task will be performed within a software project and determines the grouping of work items depending on the phase of the project. The ProjectLifecycle node is the root node for all the iterations. The LifecycleItem type defines each iteration within the whole:

              <Node Type="ProjectLifecycle" Name="ProjectLifecycle" xmlns="">           <Children>              <Node Type="LifecycleItem" Name="Plan"></Node>              <Node Type="LifecycleItem" Name="Develop"></Node>              <Node Type="LifecycleItem" Name="Test"></Node>              <Node Type="LifecycleItem" Name="Deploy"></Node>           </Children>        </Node> 

      You can also define organizational units (OU) within the Project Team in order to establish subgroups based on specialty. For example, you can have a development group that focuses on business logic, and another that focuses on Web UI. Organizational units are useful for grouping together work items and reports within these subgroups. An organizational unit can be defined using the ProjectModelHeirarchy root node:

              <Node Role="ProjectModelHierarchy" Name="ProjectModelHierarchy" xmlns="">           <Node Role="OrganizationalUnit" Name="Business Logic DevTeam"></Node>           <Node Role="OrganizationalUnit" Name="WebUI DevTeam"></Node>        </Node>     </Nodes> 

      Note

      If you change the iterations or organizational units in an existing process template, be aware that work item instance tasks may be bound to specific iterations or OUs in workitem.xml.

      The Classification plug-in can map work items to specific fields in Microsoft Project. Microsoft Project has a predefined table structure (unlike Microsoft Excel) and targets specific fields. The field map can be enabled to facilitate matching up Project fields with work items. In the following example, the Microsoft Project field map is contained in FileMapping.xml and referenced in the Classification.xml configuration file:

           <properties>        <property name="MSPROJ" value="Classification\FileMapping.xml" isFile="true" />     </properties>     </taskXml>     </task>     </tasks> 

      Here is an example of the field/work item mapping inside of FileMapping.xml.

           <MSProject>     <Mappings>     <Mapping WorkItemTrackingFieldReferenceName="System.Id"     ProjectField="pjTaskText10"     ProjectName="Work Item ID"/>     <Mapping WorkItemTrackingFieldReferenceName="System.Title"     ProjectField="pjTaskName" />     <Mapping WorkItemTrackingFieldReferenceName="System.WorkItemType"     ProjectField="pjTaskText24" />     <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Common.Discipline"     ProjectField="pjTaskText17" />     <Mapping WorkItemTrackingFieldReferenceName="System.AssignedTo"     ProjectField="pjTaskResourceNames" />     <Mapping     WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.CompletedWork"     ProjectField="pjTaskActualWork" ProjectUnits="pjHour"/>...     </Mappings>     </MSProject> 

      You should be aware of two columns in the list: the link and attachment field (LinksField) type indi- cates whether links and attachments exist for specific rows:

           <LinksField ProjectField="pjTaskText26" /> 

      The synchronization field (SyncField) type indicates whether you should use a specific column as a synchronization field:

           <SyncField ProjectField="pjTaskText25" /> 
      Note

      From a user perspective, the synchronization field will display "Sync?" in Microsoft Project, which will prompt the user to refresh or publish the row.

      Testing your classification customizations

      Follow these steps to determine whether your Organizational Units (OU) and iterations have been cre- ated successfully:

      1. Upload your custom process template to the Team Foundation Server. (See the section entitled "Upload process templates in Team Foundation Server" at the end of the chapter.)

      2. Create a new Team Project using your template. The Team Project creation process is outlined in detail in Chapter 19.

      3. Right-click on your project and select Team image from bookimage from book Areas and Iterations.

      4. Look at the Project tab to make sure that all of your custom Organizational Units are displaying correctly.

      5. Look at the Iteration tab to make sure that your custom iterations are displayed correctly.

      Groups and permissions

      You can create security groups (and associated permissions) for your project using the Group Security Service plug-in (Microsoft.ProjectCreationWizard.Groups). All of your configuration tasks are located in GroupsandPermissions.xml, and your primary folder is Groups and Permissions.

      Within the configuration file, you should define one task for each security group. Let's take a look at the components of the configuration file (GroupsandPermissions.xml). Specify a group name. In this example, the group name is Reader:

           <?xml version="1.0" encoding="utf-8" ?>     <tasks>     <task           name="Create Groups and Permissions"          plugin="Microsoft.ProjectCreationWizard.Groups"          completionMessage="Groups and Permissions created.">     <taskXml>     <groups>     <group name="Reader" description="A group for those with read access project"> 

      The permission element is then used to assign permissions to the group you created. Exhaustive lists of all permission types are available in Team System's help file:

           <permissions>     <permission name="GENERIC_READ"  deny="false" />     <permission name="SUBSCRIBE_BUILD"  deny="false" />     <permission name="GENERIC_READ"  deny="false" />     <permission name="WORK_ITEM_READ"  deny="false" />     </permissions>     </group>     </groups>     </taskXml>     </task>     </tasks> 

      In the preceding example, the Reader group has permission to read work items and other project arti- facts and to subscribe to project services.

      Verifying your custom security settings

      The best way of verifying that your custom settings and permissions were created per the specification is by following these steps:

      1. Upload your custom process template to the Team Foundation Server (see the section "Uploading process templates in Team Foundation Server" at the end of the chapter).

      2. Create a new Team Project using your template. The Team Project creation process is outlined in detail in Chapter 19.

      3. Select your Security Settings by right-clicking on your Team Project in Team Explorer.

      4. Confirm that your security groups have been created correctly in the Permissions dialog box.

      5. Pick one of the security groups and check the permissions to confirm that they are correct.

      Uploading process templates in Team Foundation Server

      Once you have customized the process template to your liking, you must re-import it into Team Foundation Server to share it with the rest of the project team members. A project manager can share your custom process by creating a new project using your process. Here are the steps to import a custom process template into Team Foundation Server:

      1. Select Process Template Manager by clicking Team Foundation Server Settings within the Team menu. The process template Manager will display all the available options (please refer to Figure 22-2).

      2. Click the Upload button and select your process template description file (ProcessTemplate.xml) using the Upload Process Template dialog box.

      3. As soon as you click the Open button, the process template will import into Team Foundation Server and will appear on the list of available processes.

      4. Close the Process Template Manager.

      Deleting process templates

      There will be times when process templates are no longer needed because they have been replaced by newer versions or they have become obsolete. We strongly recommend that you export a copy of the process template you want to delete as a backup before you take the steps to delete it. To delete a process template, simply follow these steps:

      1. Choose the Process Template Manager by selecting Team Foundation Server Settings from the Team menu. You will then see a list of all the available process templates.

      2. Pick a process template to delete and select Delete.

      According to the Visual Studio 2005 SDK documentation, deleting a process template will not affect Team Projects that were created using the template. This is because a copy of all the artifacts from the process template (documents, source code repository, permissions) has been created on the server and the project is no longer tied to the template file.

      You can then change the default template by selecting a process and clicking the Make Default button. You can then close the Process Template Manager.



    Professional Visual Studio 2005 Team System
    Professional Visual Studio 2005 Team System (Programmer to Programmer)
    ISBN: 0764584367
    EAN: 2147483647
    Year: N/A
    Pages: 220

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