Using Team Foundation Server to Develop Custom SharePoint Products and Technologies Applications

  • Article

Summary: Use Microsoft Visual Studio 2008 Team Foundation Server to support SharePoint application development, and provide an integrated development environment and single source code repository for process activities, integrated progress reporting, and team roles. (12 printed pages)

Microsoft Corporation

September 2008

Applies to: Microsoft Visual Studio 2008 Team Foundation Server, Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0

Contents

  • Introduction to Collaborative Development for SharePoint Applications Using Team Foundation Server

  • Using ALM for Collaborative Development of SharePoint Applications

  • Taking Advantage of Team Foundation Server for SharePoint Application Development

  • Creating a Team Project for SharePoint Application Development

  • Visual Studio Solution Structure Considerations for SharePoint Application Development

  • Conclusion

  • Additional Resources

Introduction to Collaborative Development for SharePoint Applications Using Team Foundation Server

Microsoft SharePoint Products and Technologies (which include Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0) provide an integrated suite of server capabilities for content management, search, and shared business processes across the extranet and intranet for your organization. Your development of applications for this complex environment can benefit from clear and well-defined processes, easily shared resources, a unified approach to application development across the team, and transparency into progress against milestones. Features in Office SharePoint Server 2007 and Windows SharePoint Services 3.0 provide some of these resources to support the development of applications for this platform. However, you can use Microsoft Visual Studio 2008 Team Foundation Server features to more fully support your application development efforts. When used with Microsoft Visual Studio 2008, Team Foundation Server provides an integrated development environment and a single source code repository that supports the process activities, the integrated reporting of progress, and the team roles involved in a software development project.

Note

For more information about incorporating Microsoft best practices and toolsets around ALM and applying them to SharePoint development, see the Application Lifecycle Management Resource Center for SharePoint Server.

Using ALM for Collaborative Development of SharePoint Applications

You can use an Application Lifecycle Management (ALM) system to help coordinate and organize the development of your SharePoint applications. SharePoint Products and Technologies are rapidly being regarded as an application development platform that provides a set of features and functionality that can help support development teams to build custom applications. Consequently, it is important for development teams to regard SharePoint application development as they consider traditional or common software development. For example, development teams should ensure that there is a clear and defined method of applying ALM concepts to the development process. There are many similarities between common application development (for example, for Windows Forms or Web applications) and SharePoint development; however, many of the specific tools, procedures, and types of development that comprise SharePoint applications need to have an ALM context applied to them.

What Is ALM?

ALM is the coordination of development life-cycle activities—including requirements, modeling, development, build, and testing—through the following areas of focus:

  • Enforcement of processes that span these activities

  • Management of relationships between development components used or produced by these activities

  • Reporting on progress of the entire development effort

Recently, ALM has expanded beyond the application and the software development life cycle to also include business solution governance, infrastructure management, operations, and support.

You can use ALM to help align your organization in the context of a software solution in business, development, and operations. With an application development platform that supports ALM, you can provide integration between the various tools used and activities performed within each of these capabilities.

Using Visual Studio Team System as an ALM Solution for SharePoint Application Development

Visual Studio Team System is an ALM solution that has particular relevance for SharePoint application development. Application development on the SharePoint platform requires knowledge not only of how to develop and make use of its capabilities and features, but how to build, release, and maintain the implemented application within a SharePoint farm. Because the capabilities of SharePoint Products and Technologies form what developers might regard as a capability framework, it is extremely important for development teams to apply ALM principles to their projects to use SharePoint features appropriately. ALM principles will ensure that the application being commissioned contains all relevant requirements documentation, a timeline for project planning, and a version control repository and build capabilities.

Role Collaboration During Solution Development

Team collaboration during software development is vital not only for the development team, but also for the extended team—including business stakeholders and operations personnel. You can promote collaboration between business roles by helping ensure everyone involved in the project has access to requirements, timelines, deliverables, and quality metrics. Visual Studio Team System includes roles and applications to help promote collaboration across the extended team. Increasing collaboration in the software development effort can result in several positive benefits:

  • Stronger collaboration between business and IT, resulting in better alignment of IT and business goals

  • Increased accountability, enabling stricter compliance with governance initiatives

  • Improved project management, including better estimation, tracking, and reporting through a single, unified view of the project

  • Quality improvements, so that the final application meets the customer's requirements and quality of service requirements

  • Increased return on investment (ROI) by increasing productivity and reducing the cost of application development

Team collaboration during the development process ensures accurate and streamlined application technical design that satisfies requirements and produces optimal solution implementation. This approach works equally well in a rapid development environment where you are producing vertical artifact-based solutions (such as site and list templates) or in long-term development of composite solutions.

Team Foundation Server Collaborative Support

The following sections provide guidance about how to take advantage of Team Foundation Server to specifically support a SharePoint application development initiative. The guidance offered contains specific details for project creation and version control configuration, and information about configuring Team Foundation Server to best support your development efforts.

Taking Advantage of Team Foundation Server for SharePoint Application Development

As with any software development effort, you need a common set of tools and processes to achieve application implementation success. Common resources that promote collaboration and facilitate team development are required elements. From a development standpoint, these elements might include a version control repository and an integrated development environment (IDE). You can use the capabilities of Team Foundation Server to provide these elements to your application development teams.

Reviewing Considerations for SharePoint Application Development

Some applications that are built on the SharePoint platform are characterized as high-impact, quick-development, artifact-based solutions. These applications might service a small or temporary audience, and might not be governed by service-level agreements (SLAs) or warrant the same operational and support footprint on an organization that a complex SharePoint solution would. Because artifact development is viewed primarily as an activity based in content development (including the alteration of master pages, style sheets, page layouts, and page content), you can choose to use the content approval workflows that are built into SharePoint Products and Technologies for solution development and deployment.

However, when solution complexity increases to include a combination of artifact and assembly development, your teams will be faced with additional considerations. Your development process will need to accommodate the integration of independently developed assemblies or artifacts, and you will need to choose strategies for version-control repositories and automated builds, and for constructing features and solution packages, and more. Also, after the initial development process is complete, deployment and operational support become primary considerations.

Using Team Foundation Server Features in SharePoint Application Development

The following sections provide information about how to implement features of Team Foundation Server in SharePoint Products and Technologies application projects.

Version Control

Team Foundation Server provides a richly featured version control repository with both basic and advanced features that include:

  • Integrated versioning

  • Atomic check-ins

  • Locking

  • Branching

  • Merging

  • Shelving

  • Customizable check-in policies

  • Work item integration

  • Reporting on version control activity

SharePoint Products and Technologies include versioning features for artifacts that reside in content databases (and thus on its sites); however, many organizations have a mandate or policy that projects must use a single enterprise version control repository.

Team Foundation Server version control integrates with Microsoft Visual Studio and Microsoft Office SharePoint Designer 2007 allows for the "online" modification of artifacts on an established SharePoint site. Office SharePoint Designer makes it very easy for developers to quickly customize or add elements to an existing SharePoint site. However, teams might have to reconcile a situation in which parts of the same overall solution have source artifacts in two separate repositories (those versioned in the SharePoint content database, and the assemblies versioned and housed in the Team Foundation Server version control repository). You can address this issue by choosing to follow one of several development team models and strategies of organizations that have adopted Team Foundation Server as an enterprise version-control and ALM platform.

Project Methodology and Planning

You can establish a foundation for process and collaboration by using Team Foundation Server. Team Foundation Server includes several default process templates, which provide the ability to implement a specified project management methodology. You can use one of these process templates when you create a team project (a Team Foundation Server container for all activity that relates to a particular software development project). The choice of process template specifies the types of work items (such as requirements, tasks, and bugs) and document templates to use in the project, and the reports that enable the tracking of project activity.

For SharePoint application development, the process template serves as a way to bring standardized project management and team project attributes to the SharePoint development initiative. For complex composite SharePoint solutions, this represents a way to apply valuable ALM principles to the collaboration features of the project.

Artifact Tracking and Reporting

A powerful feature of Team Foundation Server is the ability to associate source code checked into its repository with work items created during the development life cycle. This allows for reports that show project progress from multiple perspectives. When developing and maintaining a SharePoint feature within the Team Foundation Server version control repository (in the context of a Visual Studio solution), you and your team can use Team Foundation Server to provide quality metrics in the form of bug rates, code churn, and broken builds, and progress metrics such as the overall development effort on that particular feature.

You can also use the built-in reports included with Team Foundation Server to help monitor the progress of your application development. The tracking and reporting features of Team Foundation Server include SharePoint artifacts if the artifacts are contained within the same Visual Studio solution as the assembly components of the application.

Collaboration

In a typical installation, Team Foundation Server uses either Microsoft Office SharePoint Server 2007 or Windows SharePoint Services 3.0 for document and team collaboration purposes. The default is Windows SharePoint Services 3.0, but you can choose to configure Team Foundation Server to use a pre-existing installation of Office SharePoint Server 2007. For each team project, an associated SharePoint site is created based on a predefined definition as specified by your choice of process template. This definition includes all templates for various document-based project artifacts that need to be produced during different phases of the project. The site will include templates for design documents, requirements matrixes, and architectural diagrams. These documents can be versioned and linked to relevant project work items. Thus, the portal is considered the collaboration environment for documents, and the Team Foundation Server version control repository is the collaboration environment for source code.

Building and Deploying

Team Foundation Build is a server-based project compilation and build engine that is included with Team Foundation Server. You can use Team Foundation Build for automated builds of projects that reside in the Team Foundation Server version control repository. Similar to established application development, you also can use Team Foundation to automate the build and packaging of SharePoint projects.

If your development teams have a strategy and procedure in place to include both assemblies and artifacts as elements of the Visual Studio solution stored in the Team Foundation Server version control repository, you can use Team Foundation Build to compile and build SharePoint applications. While the design and architecture of the final deployment SharePoint application must be accommodated early in the architectural design process, you can use Team Foundation Build to implement the specified build process. You can also extend this build process to conduct deployment to target SharePoint farm environments.

SharePoint Collaborative Software Development Life Cycle

The following sections describe how you and your software development teams can use Team Foundation Server capabilities during SharePoint application development.

Role-Based Process Model for SharePoint Application Development

Team Foundation Server provides a solid base for implementing a healthy software development life cycle for SharePoint applications. As solution complexity and functionality requirements increase, your model for a complex, team-based SharePoint project can take advantage of and benefit from Team Foundation Server processes and features.

Specifically, your team development leadership, programmers, and product management should have a clear understanding of the SharePoint application development life cycle. Figure 1 shows the specification of a requirement for a SharePoint application and the processes, roles, artifacts, and procedural flow that follow to create the solution.

Figure 1. SharePoint application life-cycle process

SharePoint application life-cycle process

Example: Conception and Planning of a New SharePoint Application

In this example, a development team at Contoso is required to construct an intranet information portal that services the entire organization. The team is responsible for gathering requirements, developing solution architecture, and keeping business stakeholders up to date about completion against milestones and timelines. Business stakeholders must be able to easily supply and amend requirements so that developers can quickly see and accommodate them in the design and development. The architecture should be based on a publishing portal SharePoint site template and include artifacts (customized master pages, style sheets, page layouts, and content types) and assemblies (such as customized Web Parts and event receivers).

The Team Project Template

The project lead (either a development lead or program management) oversees the creation of a new team project by an administrator for Team Foundation Server. This new team project includes a SharePoint collaboration site—a team project portal—and templates and SharePoint libraries for project documentation, reports, and work items. The request for a new team project includes a request for a specific process template. In this example, Contoso determines that the MSF for Agile Software Development template is appropriate, given the characteristics of the project and timelines. As shown in Figure 2, after several preliminary meetings, the business stakeholders provide the development team with distilled business scenarios as Team Foundation Server work items within the new team project, named "Contoso". Developers can view and interact with this team project through the Team Explorer add-in within Visual Studio. The establishment of these work items allows developers to track business requirements against feature development. Additional Team Foundation task work items will be associated with the scenario to define, assign, and distribute the work development tasks at a more granular level and maintain traceability with the actual scenario.

Figure 2. Contoso team project scenario list

Contoso team project scenario list

To provide stakeholders with consistent and continuous exposure to progress against the specified scenarios as the project progresses and development begins, product management and program management can view the Scenario Details report that indicates the level of progress of development tasks against scenario goals. Figure 3 depicts a sample report that Contoso distributes to extended business stakeholders who want to view project progress.

Figure 3. Scenario progress report in Team Foundation Server

Scenario progress report in Team Foundation Server

For SharePoint application development, one suggested approach is to map one or more scenarios or requirements to a SharePoint Feature. The Feature Framework enables the modular management (installation, activation, deactivation, uninstallation) of SharePoint artifacts and assemblies across one or more sites or Web applications. For more information about the SharePoint Feature Framework, see Features and Templates in the Windows SharePoint Services 3.0 SDK.

A complementary approach is to also map a set of scenarios to a SharePoint solution package. Solution packages allow the inclusion of multiple features and non-feature artifacts into a single file that can be deployed across all servers in a farm.

For more information about SharePoint solutions, see Solutions Overview in the Windows SharePoint Services 3.0 SDK.

Approach to Development and Version Control

After business analysts define a particular set of requirements and scenarios, it is the architect's responsibility to determine how to implement them. The architect has to balance long-term maintainability, speed of development, reusability, integration, and extensibility requirements, and mode of deployment. These factors may influence the choice of SharePoint artifacts and assemblies to use, which in turn affects the development life cycle.

In the Contoso example, the architecture requires the inclusion of artifacts and assemblies into a consolidated solution package that will be deployed to a target SharePoint Web farm. Because there will be a high degree of dependency on artifact developers supplying their components to assembly developers (for example, to a Web part developer who needs a master page), and a need to introduce a daily build into the development process, the artifacts will be extracted from the developer's virtual SharePoint environment and included in the Visual Studio solution. During the development process, team members can take the extracted artifacts and package them as separate solution packages for installations in their team members' virtualized environments. At the same time, the main project's Visual Studio solution (that generates the solution package for the application) includes the artifacts in the larger application's solution package. This arrangement allows for the interchange of artifacts between assembly developers and the creation of a consolidated solution package for the application, and ensures that a single version control repository is used.

Team Foundation Build Procedure

Development team leads for Contoso configure a Team Foundation Build process to acquire the solution from version control and build or compile it nightly. The output of the build will eventually be extended to deploy the solution package to a target integration Web farm for testing. Eventually, the output of the build is used to deploy the entire solution into a production SharePoint Web farm.

New Feature Requests and Scope Changes

By using the Team Foundation Server collaborative features for the intranet project, the team can accommodate additional scenarios or modifications to existing scenarios. The addition or modification is easily communicated to everyone involved with the project, and the work items that are generated are eventually assigned to a developer for creation. The following scenario describes a sample process by which a new requirement is accommodated in the project by using Team Foundation Server as the project's underlying collaboration engine.

Scenario: Carousel Image Feature Addition

The business stakeholders want to add a feature to the portal before its release that requires the creation of a subsite where daily news and articles are published. These articles are published by using the SharePoint content management workflow features. The business wants the main intranet site landing page to reflect this published content in an aggregated way.

The development team's product management and program management start the following process in Team Foundation Server:

  1. The business analyst enters the scenario into Team Foundation Server.

  2. The architect evaluates several approaches, including using the Content Query Web Part and developing a custom Web Part that calls the API.

    She considers a custom Web Part that allows for more control, but decides on the Content Query Web Part for its speed of implementation and customization, and minimal coding requirements.

  3. The project manager adds a development task to the scenario in Team Foundation Server and assigns it to the architect, so that she can add the details of the chosen approach.

  4. The architect edits the development task with the details and assigns the task back to the project manager.

  5. The project manager prioritizes the development task and, optionally, assigns it to a developer.

As you can see through this example, you can use Team Foundation Server features to provide support for applying ALM and collaborative principles in a complex SharePoint development project.

Creating a Team Project for SharePoint Application Development

Before you create a team project in Team Foundation Server, you should understand configuration requirements for the development teams to be able to provide optimal support for all project participants. All participants in the team project require varying levels of permissions in a Team Foundation Server deployment. You must consider these permission requirements for all team members who will directly interact with the server. In addition, you can consider how to involve business stakeholders directly in the team project, and whether that involvement requires you to configure additional permissions for these stakeholders. By the time you finish creating and populating a team project, you should have configured permissions and groups in Team Foundation Server for all team members to have appropriate access to the team project for their role. At that time, technical development team members should be ready to start application design and creation.

To set up SharePoint application development environments for team members, each developer must have the following prerequisites configured on a physical computer or on a virtual computer image:

  • Windows Server 2003 or Windows Server 2008

  • Microsoft Office SharePoint Server 2007 SP1

  • Microsoft SQL Server 2005 SP2 Developer Edition

  • Microsoft Visual Studio 2008

  • Visual Studio extensions for Windows SharePoint Services

  • Microsoft Office SharePoint Server 2007 SDK

  • Team Explorer (the client for Team Foundation Server)

Team Foundation Server should also be installed and configured within the organization to support new team projects.

For information about setting up Microsoft Office development environments, see Setting Up Development Environments for the 2007 Microsoft Office System. For more information about installing Team Explorer and Team Foundation Server, see the Team Foundation Installation Guide for Visual Studio Team System 2008, available on the Microsoft Download Center.

After the server environment is established, you can begin configuring the Team Foundation Server features that are used during development.

Organizing Team Projects

A team project is a collection of components and resources that are used by a development team to perform and track a related set of work. All artifacts for an application development effort that are stored in Team Foundation Server should belong to a single team project. A team project is required to use Team Foundation Server features and resources. A team member, usually the project manager, specifies a process template that matches the desired approach to implementing application life cycle management principles and ensures that a security strategy is in place to provide appropriate levels of access to all individuals involved in the project. Following the process template selection and team project creation, project leadership uploads existing artifacts, and begins the definition and entry of business scenarios.

It is very important to first establish a strategy for using team projects. Careful forethought now can save you much time and effort later. For more information about structuring team projects, see Planning a Team Project and Microsoft Team Foundation Server Branching Guidance on CodePlex.

The most common strategy for creating team projects is to create one project for each SharePoint application under development. This strategy can support both large and small applications, and multiple releases of applications that are being developed in parallel. Various releases of the application are manifested in the version control system as source branches, and in other parts of Team Foundation Server as different nodes in the iteration classification hierarchy. For more information about branching, see Understanding Branching.

For more information about creating iterations, see "Use Iterations to Represent Milestones in Your Project" in Guidelines: Project Management.

Establishing Version Control Policies

You can use Team Foundation version control to provide standard source-code version control functionality. This can be scaled out to handle thousands of developers. Team Foundation version control includes the following features:

  • Complete version control feature set

  • Check-ins on a one change at a time basis

  • Branching and merging

  • Shelving

  • Check-in policies

Consider configuring Team Foundation Server to enforce check-in policies that require the developers to provide the information that your team needs for success. For example, you could configure a check-in policy that requires developers to add comments on the changes they made to the code they are checking in for this change set, and to link this check-in to a specific work item (for example, Requirement, Task, or Bug). In this way, more accurate work item reports can be generated from Team Foundation Server to the other project stakeholders, and other developers will have a clear history of the changes made in each ChangeSet and the reasoning for those changes.

For more information, see Working with Team Foundation Version Control.

Another aspect of setting up the development environment is branching source code. Most development teams working on short release cycles do not need to branch. Development teams working on longer release cycles are more likely to need branching as part of the development process. If you have one stream of development, or are performing incremental and continuous releases, you might not need to create branches unless you frequently experience breaking changes that are destabilizing your development efforts.

A common scenario for using branching in SharePoint development is to branch for release. This is the case where you need to create a branch to stabilize for a release. Your team creates a branch before release time to stabilize the release and then merges changes from the release branch back into the main source tree after the software is released. This also allows you to maintain branches with the latest version that went into each release in the event that you need to develop service packs or hot fixes for a specific release.

For more information about defining your branching and merging strategy, see Chapter 5–Defining Your Branching and Merging Strategy in the Team Development with Visual Studio Team Foundation Server Guide.

Using Continuous Integration Builds

You can configure Team Foundation Server to start a build automatically after a check-in event occurs. If your teams are developing SharePoint artifacts that involve writing code that is built into assemblies, your developers can use continuous integration builds to gain rapid feedback on build quality soon after a check-in event happens. During team development, it is important to get rapid feedback on the quality of check-ins, especially if they combine with other developers' changes and break the build. Continuous integration builds give you the chance to fix code quickly to unblock other team members, thereby improving the consistency and quality of your build.

For more information about running continuous builds in Team Foundation Server, see How to: Run Continuous Builds.

Visual Studio Solution Structure Considerations for SharePoint Application Development

After the team project is created and the design of the SharePoint application architecture begins to solidify, architects and lead developers can give careful thought to the structure of the Visual Studio solution to use to store the components of the solution under development. The following is a list of common SharePoint customizations that can be included in a Visual Studio solution:

  • Feature

  • Feature Event Receiver

  • Site Definition

  • List Definition

  • Field Type Definitions

  • Timer Job Definitions

  • Event Handler

  • Coded Workflow

  • Custom Web Part

  • Custom Layout Page

  • Feature Stapling

  • Site Template

  • List Template

  • Content Types

  • Column Template

  • Delegate Control

  • Custom Form Template

  • Custom Action

  • Workflow Activity

  • Document Converter

  • IM Policy

  • Security Policy

  • BDC Definition

  • Pluggable Authentication Provider

  • Pluggable Single Sign-On Provider

  • STSADM Command Extensions

For customizations that consist of code files only, you can create a separate project for each customization under the solution. The Visual Studio 2008 extensions for Windows SharePoint Services provide the following tools to aid developers in building SharePoint applications:

Visual Studio 2008 Project Templates

  • Web Part

  • Team Site Definition

  • Blank Site Definition

  • List Definition

  • Empty SharePoint Project

Visual Studio 2008 Item Templates (items that can be added into an existing team project)

  • Web Part

  • Custom Field

  • List Definition (with optional Event Receiver)

  • Content Type (with optional Event Receiver)

  • Module

  • List Instance

  • List Event Handler

  • Template

You can find the Visual Studio 2008 extensions for Windows SharePoint Services on the Microsoft Download Center at Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version 1.2.

Conclusion

SharePoint Products and Technologies are a flexible platform that enables the development of various customizations in a way that is very similar to common software development. Development for this environment should follow a clear and well-defined ALM process to increase quality and team productivity, and to reduce development costs. You can use Team Foundation Server to help you provide your chosen ALM process to your application development efforts.

Team-based development for SharePoint applications can take many forms. As the size of the team and the roles contained within it increases in response to the application's complexity, managing the development life cycle and ensuring a healthy collaboration environment becomes a pivotal need. Taking advantage of Team Foundation Server as a tool to support these processes can help you manage needs as you manage the project. Visual Studio Team System provides an integrated environment and a single repository that supports the process activities and the team roles involved in a software development project.

Additional Resources

For additional information about SharePoint Products and Technologies, see the following resources: